From owner-freebsd-bugs Tue May 2 21:10:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 4DA4337BD3B for ; Tue, 2 May 2000 21:10:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id VAA72263; Tue, 2 May 2000 21:10:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefour.acs.rpi.edu (freefour.acs.rpi.edu [128.113.24.91]) by hub.freebsd.org (Postfix) with ESMTP id B9CE437BCFE for ; Tue, 2 May 2000 21:02:33 -0700 (PDT) (envelope-from gad@freefour.acs.rpi.edu) Received: (from gad@localhost) by freefour.acs.rpi.edu (8.9.3/8.9.3) id AAA70738; Wed, 3 May 2000 00:02:32 -0400 (EDT) (envelope-from gad) Message-Id: <200005030402.AAA70738@freefour.acs.rpi.edu> Date: Wed, 3 May 2000 00:02:32 -0400 (EDT) From: Garance A Drosehn Reply-To: gad@eclipse.acs.rpi.edu To: FreeBSD-gnats-submit@freebsd.org Cc: gad@eclipse.acs.rpi.edu X-Send-Pr-Version: 3.2 Subject: bin/18361: [PATCH] Fix for queue-ordering problem in lpr/lpd/lpq Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >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