Path: utzoo!utgpu!watserv1!watmath!att!bellcore!bellcore-2!rutgers!mit-eddie!aryeh
From: aryeh@eddie.mit.edu (Aryeh M. Weiss)
Newsgroups: comp.unix.xenix
Subject: Re: Serial Printer Problem (fixing the scheduler problem)
Message-ID: <1990Jul21.135211.19644@eddie.mit.edu>
Date: 21 Jul 90 13:52:11 GMT
References: <2070@lakesys.lakesys.com> <1990Jul19.112309.5174@eddie.mit.edu> <1650@ispi.COM>
Reply-To: aryeh@eddie.MIT.EDU (Aryeh M. Weiss)
Organization: MIT EE/CS Computer Facilities, Cambridge, MA
Lines: 30

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 ...

--