Bug 21007

Summary: [MFC] Improve/fix error messages in lpr's recvjob processing
Product: Base System Reporter: Garance A Drosehn <gad>
Component: binAssignee: Garance A Drosehn <gad>
Status: Closed FIXED    
Severity: Affects Only Me CC: gad
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description Garance A Drosehn 2000-09-03 05:20:00 UTC 
	When lpd is receiving jobs, there are several error checks where
	it calls an 'frecverr' routine.  That FIRST calls a cleanup routine,
	and THEN sends a given message to syslog.  The problem is that the
	cleanup routine may zero out some of the fields included in the
	error message, thus making the error message less useful.

	Also, frecverr sends two syslog messages.  the first one is nothing
	but a hostname, which seems meaningless if you're looking at syslog
	error messages and you are not aware of what lpd is doing.  I thought
	it could stand to be a bit more meaningful.

Fix: Here's an update:
How-To-Repeat: 
	Use lpd on a printserver.  Send jobs.  Get errors.  Look at syslog.
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 2000-09-05 11:26:39 UTC 
Responsible Changed
From-To: freebsd-bugs->sheldonh

I'll take this one.
Comment 2 Garrett Wollman freebsd_committer freebsd_triage 2000-09-27 20:27:44 UTC 
State Changed
From-To: open->feedback

I'm a bit concerned about the sleep(2) you added, which is not explained 
anywhere in the PR.  Debugging code, or meaningful?
Comment 3 Garrett Wollman freebsd_committer freebsd_triage 2000-09-27 20:27:44 UTC 
Responsible Changed
From-To: sheldonh->wollman

I'm working on it.
Comment 4 gad 2000-09-28 03:38:44 UTC 
Garrett writes:
> I'm a bit concerned about the sleep(2) you added, which is not
> explained anywhere in the PR.  Debugging code, or meaningful?
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=21007

Minor safety throttle.  The error message being returned (by the
'putchar()' call right after the sleep) is going to the remote
host.  The remote host, which could be running any implementation
of lpr, could decide to IMMEDIATELY retry the send.  I like the
idea of writing a message to syslog, then waiting a bit before
telling the other side that they might want to retry.  It makes it
less likely that an error (*) on some remote machine will flood
logfiles on this machine.  As for the process on the print server,
all it's going to do is exit anyway, so I wouldn't expect any
problem in delaying that exit.

(*) in this case, "error" means "awful implementation of lpr"...

I can't say that I have ever seen some remote machine flood one of
our print servers due to a problem like this, and I'm not all that
tied to the sleep being there.  I initially put it there just for
debugging purposes, but then I didn't really see any reason to
remove it when sending in the PR.  The sleep isn't necessary for
any of this to work, so if it's the potential for any problem then
it certainly can be removed.

---
Garance Alistair Drosehn     =     gad@eclipse.acs.rpi.edu
Senior Systems Programmer        (MIME & NeXTmail capable)
Rensselaer Polytechnic Institute;           Troy NY    USA
Comment 5 Garance A Drosehn freebsd_committer freebsd_triage 2000-11-05 02:24:42 UTC 
State Changed
From-To: feedback->suspended

The patch for fixing this error handling has been applied to current. 
Awaiting a good time to MFC.
Comment 6 Garance A Drosehn freebsd_committer freebsd_triage 2000-11-05 02:24:42 UTC 
Responsible Changed
From-To: wollman->gad

This is another lpr-related PR which I had sent in, and which I might as 
well clear out now that I have commit access...
Comment 7 Garance A Drosehn freebsd_committer freebsd_triage 2000-12-27 17:07:12 UTC 
State Changed
From-To: suspended->closed

Fix has been applied to both -current and -stable.