[comp.unix.questions] What does waiting for lock on /dev/... mean"

fredrick@acd.ucar.edu (Tim Fredrick) (12/13/90)

We have this recurring problem on our PostScript printers which are
accessed via a GatorBox on a LocalTalk network.  The UNIX print spoolers
will occasionally get into a state where they will not try to send
anything to the PostScript printer.  The message on lpq looks like:

wk1:/ # lpq
waiting for lock on /dev/acdps2
Rank   Owner      Job  Files                                 Total Size
1st    root       18   /usr/spool/qdaemon/tI8QCGy            8123 bytes

There is only one UNIX computer trying to print to these printers, but
there are PCs and MacIntoshes which are also trying to print.

Does anyone have any insight or know how I can restore the print queues
once we see this?  BTW is it related to the rpc.lockd daemon?  This is
on a Sun SPARCstation running SUNOS4.1.  Any insight or comments would
be appreciated.  Thanks in advance.  --Tim
.


Tim Fredrick             National Center for Atmospheric Research
                         Atmospheric Chemistry Division
fredrick@ncar.ucar.edu   PO Box 3000
fredrick@ncar.CSNET      Boulder, CO 80307

dsg@mbunix.mitre.org (Goldberg) (12/13/90)

> wk1:/ # lpq
> waiting for lock on /dev/acdps2
> Rank   Owner      Job  Files                                 Total Size
> 1st    root       18   /usr/spool/qdaemon/tI8QCGy            8123 bytes

> There is only one UNIX computer trying to print to these printers, but
> there are PCs and MacIntoshes which are also trying to print.

> Does anyone have any insight or know how I can restore the print queues
> once we see this?  BTW is it related to the rpc.lockd daemon?  This is
> on a Sun SPARCstation running SUNOS4.1.  Any insight or comments would
> be appreciated.  Thanks in advance.  --Tim

My bet is that /dev/acdps2 is a hard link to /dev/null, and that there
are other such hard links for other printers.  The lpd program uses
the lock files to prevent subsequently started lpd's from messing up
the queue.  I believe that if you delete the hard links to /dev/null
and just touch those files (ie creating a separate lock for each
printer), you will be OK.  This worked for ethernet connected Imagen
printers.  I don't know how it will work for whatever software you are
using to talk to the Gator box.

#include<std.disclaimer.h>
--
Dave Goldberg                     UNIX Systems Programmer/Administrator
The Mitre Corporation   MS B020  Bedford, MA 01730        617-271-2460
Domain: dsg@mbunix.mitre.org    UUCP: {your neighborhood}!linus!mbunix!dsg