Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 May 2000 00:02:32 -0400 (EDT)
From:      Garance A Drosehn <gad@freefour.acs.rpi.edu>
To:        FreeBSD-gnats-submit@freebsd.org
Cc:        gad@eclipse.acs.rpi.edu
Subject:   bin/18361: [PATCH] Fix for queue-ordering problem in lpr/lpd/lpq
Message-ID:  <200005030402.AAA70738@freefour.acs.rpi.edu>

next in thread | raw e-mail | index | archive | help

>Number:         18361
>Category:       bin
>Synopsis:       [PATCH] Fix for queue-ordering problem in lpr/lpd/lpq
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue May  2 21:10:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Garance A Drosehn
>Release:        FreeBSD 4.0-RELEASE i386
>Organization:
RPI; Troy NY
>Environment:

	Probably any version of lpr, from freebsd-3.x to freebsd-5.x.

>Description:

	If a single task rapidly sends many separate jobs to a printer
	queue, the jobs will not necessarily print in the order they
	were sent.  The problem is that if the jobs are sent fast enough,
	then several consecutive jobs will have the same last-modification
	time on their control files.  In this situation, lpd/lpq will print
	those jobs in a random order (depending on what other files are in
	the queue).  The order of a given set of jobs can even change as
	later jobs are added to the queue.

>How-To-Repeat:

	You usually need a lot of jobs in the queue to notice the problem,
	and you need to send them rapidly.  I used a shell loop:
		lpc stop lp
		for ii in 1 2 3 4 5 6 7 8 9 10  ; do
		   lpr /tmp/lpf1 ; lpr /tmp/lpf_2 ; lpr /tmp/lpf3_3
		   lpr /tmp/lpf44_4 ; lpr /tmp/lpf555_5 ; lpr /tmp/lp--
		done
	where /tmp/lpf1, /tmp/lpf_2, /tmp/lpf3_3, /tmp/lpf44_4,
	/tmp/lpf555_5, and /tmp/lp-- (with two trailing minus signs)
	are just very tiny dummy-files.  By chosing gradually-longer
	filenames, it's easier to see what's happening in lpq.  So,
	do the above, and then 'lpq' to see if the jobs are listed
	in the same order they were sent.

>Fix:
	
	Fix the compar() routine in lpr/common_source/common.c to sort
	based on job-id (which is part of the control-file filename)
	when the last-modification time of two cf files is the same.
	Here is a patch which does this:

--- common_source/common.c.orig	Fri Aug 27 21:16:47 1999
+++ common_source/common.c	Tue May  2 23:06:07 2000
@@ -175,11 +175,24 @@
 compar(p1, p2)
 	const void *p1, *p2;
 {
-	if ((*(struct queue **)p1)->q_time < (*(struct queue **)p2)->q_time)
+	const struct queue *qe1, *qe2;
+	qe1 = *(const struct queue **)p1;
+	qe2 = *(const struct queue **)p2;
+	
+	if (qe1->q_time < qe2->q_time) return(-1);
+	if (qe1->q_time > qe2->q_time) return(1);
+	/*
+	 * At this point, the two files have the same last-modification time.
+	 * return a result based on filenames, so that 'cfA001some.host' will
+	 * come before 'cfA002some.host'.  Since the jobid ('001') will wrap
+	 * around when it gets to '999', we also assume that '9xx' jobs are
+	 * older than '0xx' jobs.
+	*/
+	if ((qe1->q_name[3] == '9') && (qe2->q_name[3] == '0'))
 		return(-1);
-	if ((*(struct queue **)p1)->q_time > (*(struct queue **)p2)->q_time)
+	if ((qe1->q_name[3] == '0') && (qe2->q_name[3] == '9'))
 		return(1);
-	return(0);
+	return(strcmp(qe1->q_name,qe2->q_name));
 }
 
 /* sleep n milliseconds */

>Release-Note:
>Audit-Trail:
>Unformatted:


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005030402.AAA70738>