davef@lakesys.lakesys.com (Dave Fenske) (07/19/90)
Has anyone ever encountered a Xenix problem in which the print spooler hangs when a print job is cancelled. This occurs on a serial port, BTW. In answer to the next question, YES, the infamous patch to hold the port open is already on the machine that's having this problem.
aryeh@eddie.mit.edu (Aryeh M. Weiss) (07/19/90)
In article <2070@lakesys.lakesys.com> davef@lakesys.UUCP (Dave Fenske) writes: >Has anyone ever encountered a Xenix problem in which the print spooler >hangs when a print job is cancelled. This occurs on a serial port, BTW. > Yes, this seems to happen when you cancel the job at the top of the queue (the job that is currently printing). Canceling a job lower down on the queue works okay. Usually the result is `lpsched' dies leaving some child processes behind. Starting the scheduler up again then usually fixes the problem. I ended up writing a fake `lp' that would check to see if the scheduler was running and respawn it if not, then call the real `lp'. However, other times lpsched truely hangs (its running but not doing anything). Sometimes even killing it off and restarting it doesn't do any good! Lpsched just sits there with a dozen jobs on the queue with the printer idle! I have to reboot! I think that lpsched must use some obscure system resource which the system runs out of, but there is nothing I can think of that would cause this behavior. Time to find a good PD lp package. --
jbayer@ispi.COM (Jonathan Bayer) (07/20/90)
aryeh@eddie.mit.edu (Aryeh M. Weiss) writes: >In article <2070@lakesys.lakesys.com> davef@lakesys.UUCP (Dave Fenske) writes: >>Has anyone ever encountered a Xenix problem in which the print spooler >>hangs when a print job is cancelled. This occurs on a serial port, BTW. >> >Yes, this seems to happen when you cancel the job at the top of the queue >(the job that is currently printing). Canceling a job lower down on the >queue works okay. Usually the result is `lpsched' dies leaving some >child processes behind. Starting the >scheduler up again then usually fixes the problem. I ended up writing a fake >`lp' that would check to see if the scheduler was running and respawn it >if not, then call the real `lp'. >However, other times lpsched truely hangs (its running but not doing >anything). Sometimes even killing it off and restarting it doesn't do >any good! Lpsched just sits there with a dozen jobs on the queue with >the printer idle! I have to reboot! I think that lpsched must use >some obscure system resource which the system runs out of, but there >is nothing I can think of that would cause this behavior. Time to find >a good PD lp package. >-- No. There is a race condition in the scheduler. It can be fixed as follows: 1. Create a new printer, call it dummy 2. Make this new printer the system default printer 3. In the file /etc/profile add the following line: LPDEST=printer; export LPDEST Replace "printer" with what you normally use as your default printer. To restart the scheduler working properly, perform the following steps: 1. Type: /usr/lib/lpshut to shut the scheduler 2. Type: ps -ae | grep lp to get the pids of all children of the scheduler. 3. kill all the children using a kill -9 4. Remove the files (if they exist): /usr/spool/lp/FIFO /usr/spool/lp/SCHEDLOCK /usr/spool/lpd/* 5. Restart the scheduler by typing: /usr/lib/lpsched JB -- Jonathan Bayer Intelligent Software Products, Inc. (201) 245-5922 500 Oakwood Ave. jbayer@ispi.COM Roselle Park, NJ 07204
aryeh@eddie.mit.edu (Aryeh M. Weiss) (07/21/90)
In article <1650@ispi.COM> jbayer@ispi.COM (Jonathan Bayer) writes: >aryeh@eddie.mit.edu (Aryeh M. Weiss) writes: > > >>However, other times lpsched truely hangs (its running but not doing >>anything). Sometimes even killing it off and restarting it doesn't do >>any good! Lpsched just sits there with a dozen jobs on the queue with >>the printer idle! I have to reboot! ... >>-- > >No. There is a race condition in the scheduler. It can be fixed as follows: > >1. Create a new printer, call it dummy >2. Make this new printer the system default printer ... > >To restart the scheduler working properly, perform the following steps: > ... I can believe this, but ... this doesn't explain to me why, when I shut down lp (properly), kill all the lp children, cancel all jobs, remove the lock and pipe, remove other miscellaneous files, remove and re-install the default printer, then restart the scheduler (properly), lp still doesn't work (sometimes). What's special about the default printer (besides being special)? Under what circumstances does this race condition occur? And I think a reliable PD lp replacement is still a good idea ... --
barton@holston.UUCP (Barton A. Fisk) (07/24/90)
In article <2070@lakesys.lakesys.com>, davef@lakesys.lakesys.com (Dave Fenske) writes: > Has anyone ever encountered a Xenix problem in which the print spooler > hangs when a print job is cancelled. This occurs on a serial port, BTW. > I have one site running an old version of xenix sco 2.1.3 and this will happen occasionally. My site which is running 2.2.1 never has this problem. -- uucp: holston!barton