Summary: "waiting for lock on /dev/laserwriter"

From: Ian Reddy (ian@whistler.sfu.ca)
Date: Tue Nov 20 1990 - 20:34:50 CST


My apologies to the list for taking so long to summarise.

I received 9 replies, all of which provided more of a workaround
than a solution to the problem (though I didn't explain it very well).
Here is the original question:

>The lpd system tells me that there is a lock applied to the laserwriter device
>(actually /dev/ttyb). Is there any way to remove this short of rebooting the
>Sun 4/280? Maybe someone has a piece of code that will investigate locks and
>their status and possibly change them?

The lock is not due to a "lock file" such as lpd.lock but appears to
be either an advisory or mandatory lock applied to the device file.
I would like to REMOVE this lock. The best one can do it seems is to
remove the device file altogether and immediately recreate it using
"mknod" as implied in the replies of David Skoll and Scott Paisley.

Many thanks to the following:

dfs@doe.carleton.ca (David F. Skoll)
bs30%sirius@gte.com (Bernard Silver)
vasey@mcc.com (Ron Vasey)
Jeff Nieusma <nieusma@eclipse.Colorado.EDU>
uunet!chron!magic706!sysnmc (Matt Cohen)
uunet!world.std.com!bzs (Barry Shein)
hbo!bice (Brent A. Bice)
paisley@cme.nist.gov (Scott Paisley)

The replies in full follow (my comments are surrounded by "[[[ ]]]"s):

*****************************
From: dfs@doe.carleton.ca (David F. Skoll)

We were having exactly the same problem - we still don't know what causes it.
However, the following script will correct the problem, at the expense of
losing the currently-active printer job. But at least you won't have to
reboot.

WARNING: Read the script before running it!! Certain parameters may need
to be changed - these are clearly indicated with a # WARNING comment.

[[[ Could have used this script but just did a rm/mknod as needed. ]]]
[[[ Note fix that follows this response if you use this script. ]]]

Hope this helps.

--
David F. Skoll                              Department of Electronics
dfs@doe.carleton.ca                         Carleton University
(613) 786-7515                              Ottawa, Ontario, Canada

----- CUT HERE ------ #! /bin/csh -f # # C-Shell script to fix the deadlock problem with the line printer daemon # # By David Skoll - 7 September 1990 #

# WARNING Change this test as applicable - our print server machine is called scotty if ("`hostname`" != "scotty") then echo "The fix.lpd shell script must be run on scotty." exit 1 endif

if (`whoami` != "root") then echo "You must be root to run the fix.lpd shell script." exit 1 endif

alias findproc 'ps -auxww | grep \!* | grep -v "grep \!*"'

# WARNING Change the "ttyb" to your printer port echo " " echo "Deleting and recreating /dev/ttyb..." rm /dev/ttyb

# WARNING Change the parameters below to match your printer port mknod /dev/ttyb c 12 0

echo "Searching for lpd processes..." set n = `findproc "/usr/lib/lpd" | wc -l`

if ("$n" == "0") then echo "No lpd processes found to kill." else echo "Killing $n lpd process(es) $procs..." set procs = `findproc /usr/lib/lpd | awk '{print $2}'` kill -9 $procs endif

echo "Searching for pscomm processes..." set n = `findproc "pscomm" | wc -l`

if ("$n" == "0") then echo "No pscomm processes found to kill." else echo "Killing $n pscomm process(es) $procs..." set procs = `findproc pscomm | awk '{print $2}'` kill -9 $procs endif

echo "Starting lpd..." /usr/lib/lpd

sleep 5 echo "Restarting printers..." lpc restart all

unalias findproc

echo "fix.lpd is done." exit 0

*****************************

From: dfs@doe.carleton.ca (David F. Skoll)

Sorry about this - there's a (non-fatal) bug in the fix.lpd script I sent you... remove the "$procs" from the two "echo" lines when it's killing lpd and pscomm. Again, sorry about that.

-- David Skoll

*****************************

From: bs30%sirius@gte.com (Bernard Silver)

Have you looked in /usr/spool/locks ? (Under 4.1 anyway) There may a file there called something like LCK.ttyb Just rm it.

[[[ I don't do uucp or anything else with ttyb. ]]]

*****************************

From: vasey@mcc.com (Ron Vasey)

(Assuming you have root access) ... If lpc(8) won't do the trick, this code (from /etc/rc) should:

if [ -f /usr/lib/lpd ]; then >>> rm -f /dev/printer /var/spool/lpd.lock /usr/lib/lpd; echo -n ' printer' fi

I believe /dev/printer is a named pipe (or something like that). You might also check/remove lock files in the device spool directories.

Hope this helps ... [or did I miss the point entirely?]

[[[ This appears to be a lock applied by (via?) the kernel and not ]]] [[[ related to "lock files". ]]]

-- Ron vasey@mcc.com M.C.C. Experimental Systems (512) 338-3461 uunet!mcc.com!vasey 3500 W. Balcones Center Dr. Austin TX 78759

*****************************

From: Jeff Nieusma <nieusma@eclipse.Colorado.EDU>

did you try killing all the lpd's and restarting one?

[[[ Yes. ]]] +-----------------------------------------------------------------------------+ | Jeff Nieusma Logical: nieusma@boulder.colorado.edu | | System Administrator/Programmer Audible: (303) 492-0677 | | Computer Science Department Physical: Campus Box 430 | | University of Colorado Boulder, CO 80309-0430 | +-----------------------------------------------------------------------------+ | Work exists only to make play more fun, so if play is fun enough, why work? | +-----------------------------------------------------------------------------+

*****************************

From: uunet!chron!magic706!sysnmc (Matt Cohen)

The message "waiting for lock on <file>" means that you have more than one process trying to open the port at the same time. Look and see if you have more than 1 lpd + 1 lpd per active printer. Try killing any process that looks like an input or output filter (possibly ??of or ??if), and lastly all lpd processes except the one with the lowest pid. Check to make sure that no two entries in /etc/printcap have the same lp= entry.

Good luck!

-- Matt

[[[ Filters have given me this problem before and I simply kill them ]]] [[[ but they are not at fault here. /etc/printcap is OK. ]]]

Matt Cohen INET: sysnmc@chron.com Department of Technology Resources UUCP: ...!uunet!chron!sysnmc The Houston Chronicle AT&T: +1 713 220 7023 801 Texas Avenue, Houston, TX 77002 "The opinions above are most likely "Houston's Leading Information Source" those of my employer."

*****************************

From: uunet!world.std.com!bzs (Barry Shein)

Almost certainly just a file in its print spool directory (should be mentioned in the printcap entry), do an "ls -a" and look for a file like .lock or similar. If it's zero length just remove it, if it's not see if it's a text file that contains something like LOCKED and maybe remove it anyhow (at that point i'd rename it and see what happens usually the software re-creates it.)

You might also look and see if /usr/spool/uucp/LCK..ttyb (or whatever it is) exists and if so remove that.

It might just clear up if you run /usr/etc/lpc as root and give some obvious sequence of commands like abort, stop, start.

-Barry Shein

[[[ Again, this is a an advisory or mandatory lock on the file not a ]]] [[[ "lock file" problem. ]]]

Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD

*****************************

From: hbo!bice (Brent A. Bice)

You might check /usr/spool and /usr/spool/uucp for lock files. I don't remember for sure xactly where they are (and I'm at home, so I can;t go looking right now) but several programs toss lock files in /usr/spool for /dev/ttya /dev/cua0 and /dev/ttyd0 (and of course for other serial devices). Hope this is helps.......

[[[ See previous reply. ]]]

Brent Bice Applied Computing Systems 2075 Trinity Drive Suite Lower Level Los Alamos, NM 87544 Voice:(505) 662-3309 Fax:(505) 662-3518 bice@atlantis.ees.anl.gov % I program, therefore I am.

*****************************

From: paisley@cme.nist.gov (Scott Paisley)

We have a program here which is written in a script language called expect. To get expect you can ftp anonymous to durer.cme.nist.gov.

But to answer your question:

on the print server,

1) run lpc and 'stop printer' 2) exit lpc and cd /dev 3) get the major and minor device numbers from the printer device i.e. ls -l /dev/<printername> 4) rm the lock file and the printer device i.e. rm /var/spool/<printername>/lock /dev/<printername> 5) recreate the printer device i.e. mknod <printername> c majornum minornum 6) run lpc and 'start printer'

that will unlock the printer MOST of the time and you don't have to reboot! Good luck!

[[[ Bingo. Though I would still like to remove the lock, not the file. ]]]

-Scott (paisley@cme.nist.gov)

P.S. If you get expect, here's the script we use to unlock the printers.

-------------------------------------------------------------------- #!/usr/local/bin/expect -f

# This script unhangs a printer which claims it is "waiting for lock". # Written by Don Libes. Based on English instructions from Scott Paisley.

if {[length $argv] != 3} { send_user usage: lpunhang <printer> <server>\n exit }

set printer [index $argv 1] set server [index $argv 2]

# login to the print server as root. Set timeout high because login is slow. set timeout 60 spawn rlogin $server -l root expect timeout exit \ eof exit \ *Password* { send_user \ncouldn't login to $server as root\n; exit } \ *1#* set timeout 10

# run lpc and 'stop printer' send lpc\r ; expect *lpc>* send stop $printer\r ; expect *unknown* exit \ *disabled*lpc>*

# exit lpc and cd /dev send quit\r ; expect *#* send cd /dev\r ; expect *#*

# figure out major/minor device numbers send ls -l /dev/$printer\r ; expect *crw*#* scan $expect_match "ls -l %*s %*s 1 root %d, %d" major minor

# delete the lock and the printer device itself send rm /var/spool/$printer/lock /dev/$printer\r ; expect *#*

# recreate the printer device send mknod $printer c $major $minor\r ; expect *#*

# run lpc and 'start printer' send lpc\r ; expect *lpc>* send start $printer\r ; expect *started*lpc>* send quit\r ; expect *#*

# logout send exit\r ; expect eof

send_user Printer unlocked and restarted.\n

*****************************



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:59 CDT