Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: libes@cme.nist.gov (Don Libes)
Newsgroups: comp.sys.sun
Subject: Re: lpr lock problem under Sun4.0.3
Keywords: Source
Message-ID: <678@brchh104.bnr.ca>
Date: 8 Dec 90 22:07:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 20
Approved: Sun-Spots@rice.edu
X-Original-Date: 5 Dec 90 15:05:08 GMT
X-Refs:  Original: v9n383
X-Sun-Spots-Digest: Volume 9, Issue 389, message 8
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

In article <522@brchh104.bnr.ca> millercb@phoenix.princeton.edu (Clifford B Miller) writes:
>4.0.3.  Every once in a while, one of the printers gets into a state where
>it's "waiting for lock on /dev/ttyN" where N is the printer device.  No
>combination of lpc commands seems to remedy this...I've had to physically
>disconnect the printer from the serial port to get rid of this state.  I
>have also tried things like sending an end-of-file character to the
>printer.  What does this state really mean?  What is lpd really waiting
>for?  Any suggestions to remedy this situation would be greatly
>appreciated!

I have a program that cures that state by resetting various things.
'lpunlock' comes as an example in the 'expect' distribution.  (It needs
expect because it uses lpc, and it also figures out if the printer is
remote and rlogin's to it with root privs if necessary.)

expect may be ftp'd as pub/expect.shar.Z from durer.cme.nist.gov.  Request
email delivery by mailing to "library@cme.nist.gov".  The contents of the
message should be (no subject line) "send pub/expect.shar.Z".

Don Libes          libes@cme.nist.gov      ...!uunet!cme-durer!libes