Recently, I wrote.
>I have a HP1600CM connected to our network. Occasionally, our Sparc
>systems can't print to the printer. The only cure I've found to date is
>to reboot the Sparc. It's running 2.7 right now.
>When it stops working lpstat pretty much always says...
># lpstat -t
>scheduler is running
>system default destination: BALCH1600
>device for dummy: /dev/term/a
>device for BALCH1600: /dev/BALCH1600
>dummy accepting requests since Mon Jan 24 15:14:25 EST 2000
>BALCH1600 accepting requests since Mon Jan 24 15:14:25 EST 2000
>printer dummy is idle. enabled since Mon Jan 24 15:14:20 EST 2000. available.
>printer BALCH1600 waiting for auto-retry. available.
> Failed to open the printer port. (Resource temporarily unavailable)
>BALCH1600 was created with Jetadmin version D.06.21.
>I can print test jobs from jetadmin, just not with lp
>If I use...
>/opt/hpnp/bin/hpnpf -n -R -x BALCH1600 filename
>it works, lp doesn't.
>Any ideas? How does one go about chasing down "resource unavailable"
>errors to find out which resource (and why doesn't it tell me which one???)
I heard from several people who made various suggestions, none of which worked.
>Any chance you have an NT box that is also a print server or you have NT
>workstations printing directly to that printer? I had a problem about two
>years ago where the NT box would utilize the printer and then not release
>the port. There is an option to release at the end of job in NT. If you have
>NT boxes, this would be a good place to start.
Nope, no NT boxes on the network. There are a bunch of W95 and Macs as
well as another _identical_ Sun that can print.
>did you install your jetadmin over an existing on? Sometimes it doesn't work
>correctly and you may have to remove and re-add the printer to your remote
Nope, fresh install
>You might try using the following commands to restart the print
>queue instead of rebooting:
Tried that, no luck
># Print Protocol Adaptor - BSD listener
>printer stream tcp nowait root /usr/lib/print/in.lpd in.lpd
No but this is a "client" in this case.
>Same error message appears using NFS between two SUN machine. It's 90% of
>time because the time is different for more than 1 minutes between the 2
As far as I know, the HP doesn't have an on-board clock, nor does it use
A "quasi-suitable" work-around we found is to use '/opt/hpnp/bin/hpnpf -n
-R -x BALCH1600' instead of 'lp'. Since that works, it seems to me the
problem is "somewhere" in lp but I don't know where...
Bruce Bowler 207.633.9600 (voice)
Research Associate 207.633.9641 (fax)
Bigelow Laboratory for Ocean Sciences email@example.com
West Boothbay Harbor ME 04575 http://www.bigelow.org/
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:02 CDT