From gad@freefour.acs.rpi.edu  Sat Sep  2 21:14:59 2000
Return-Path: <gad@freefour.acs.rpi.edu>
Received: from freefour.acs.rpi.edu (freefour.acs.rpi.edu [128.113.24.91])
	by hub.freebsd.org (Postfix) with ESMTP id 2E61A37B424
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  2 Sep 2000 21:14:59 -0700 (PDT)
Received: (from gad@localhost)
	by freefour.acs.rpi.edu (8.9.3/8.9.3) id AAA73848;
	Sun, 3 Sep 2000 00:14:58 -0400 (EDT)
	(envelope-from gad)
Message-Id: <200009030414.AAA73848@freefour.acs.rpi.edu>
Date: Sun, 3 Sep 2000 00:14:58 -0400 (EDT)
From: Garance A Drosehn <gad@freefour.acs.rpi.edu>
Reply-To: gad@eclipse.acs.rpi.edu
To: FreeBSD-gnats-submit@freebsd.org
Cc: gad@eclipse.acs.rpi.edu
Subject: Improve/fix error messages in lpr's recvjob processing
X-Send-Pr-Version: 3.2

>Number:         21007
>Category:       bin
>Synopsis:       [MFC] Improve/fix error messages in lpr's recvjob processing
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    gad
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 02 21:20:00 PDT 2000
>Closed-Date:    Wed Dec 27 09:07:12 PST 2000
>Last-Modified:  Wed Dec 27 09:08:13 PST 2000
>Originator:     Garance A Drosehn
>Release:        FreeBSD 4.-stable and 5.-current i386
>Organization:
RPI ; Troy, NY
>Environment:

	Just running lpr...
	More precisely, running lpd on a print-server machine, which
	is accepting jobs from other hosts.

>Description:

	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.

>How-To-Repeat:

	Use lpd on a printserver.  Send jobs.  Get errors.  Look at syslog.

>Fix:
	
	Here's an update:

--- recvjob.c.orig	Fri Aug 27 21:16:53 1999
+++ recvjob.c	Sat Sep  2 23:39:25 2000
@@ -367,10 +367,14 @@
 #else
 	va_start(ap);
 #endif
-	rcleanup(0);
-	syslog(LOG_ERR, "%s", fromb);
+	syslog(LOG_ERR, "while receiving job from %s:", fromb);
 	vsyslog(LOG_ERR, msg, ap);
 	va_end(ap);
+	/* don't call rcleanup until AFTER logging the error message,
+	 * because rcleanup will zap some variables which may have been
+	 * given as parameters in that msg... */
+	rcleanup(0);
+	sleep(2);
 	putchar('\1');		/* return error code */
 	exit(1);
 }


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->sheldonh 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Tue Sep 5 03:26:39 PDT 2000 
Responsible-Changed-Why:  
I'll take this one. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21007 
State-Changed-From-To: open->feedback 
State-Changed-By: wollman 
State-Changed-When: Wed Sep 27 12:27:44 PDT 2000 
State-Changed-Why:  
I'm a bit concerned about the sleep(2) you added, which is not explained 
anywhere in the PR.  Debugging code, or meaningful? 


Responsible-Changed-From-To: sheldonh->wollman 
Responsible-Changed-By: wollman 
Responsible-Changed-When: Wed Sep 27 12:27:44 PDT 2000 
Responsible-Changed-Why:  
I'm working on it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21007 

From: Garance A Drosehn <gad@eclipse.acs.rpi.edu>
To: wollman@FreeBSD.org
Cc: sheldonh@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/21007: Improve/fix error messages in lpr's recvjob processing
Date: Wed, 27 Sep 2000 22:38:44 -0400

 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
 
State-Changed-From-To: feedback->suspended 
State-Changed-By: gad 
State-Changed-When: Sat Nov 4 18:24:42 PST 2000 
State-Changed-Why:  
The patch for fixing this error handling has been applied to current. 
Awaiting a good time to MFC. 


Responsible-Changed-From-To: wollman->gad 
Responsible-Changed-By: gad 
Responsible-Changed-When: Sat Nov 4 18:24:42 PST 2000 
Responsible-Changed-Why:  
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... 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21007 
State-Changed-From-To: suspended->closed 
State-Changed-By: gad 
State-Changed-When: Wed Dec 27 09:07:12 PST 2000 
State-Changed-Why:  
Fix has been applied to both -current and -stable. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21007 
>Unformatted:
