Subject: [netatalk-admins] LaserWriters and "idle bug"
From: Lasse Hillerĝe Petersen (lassehp@imv.aau.dk)
Date: Thu Jun 04 1998 - 06:19:50 EDT
(I posted this yesterday on comp.protocols.appletalk, but maybe someone on
this list could help.)
In the past we have been using CAP for print spooling/accounting, and back
then I sometimes observed "idle bug: restarting" in the log.
Due to repeating problems with printing, which always happened when many
students try to print out their papers the day they are due, I bought a
new server and Xinet KASpool. I built a new accounting system onto KASpool
based on my old CAP one, but my system unfortunately still relies on the
CAP papif program running on the old server to get the pagecounter (I am
using a modified papif which only gets the pagecount.)
Now I want to switch to using Netatalk on MkLinux for the same purpose
(getting the page counter from a printer only), until Xinet get around to
deliver a print accounting system. The reason I have to use a separate
system to get the page counter is because Xinet doesn't deliver a tool
that provides reliable page counts.
Unfortunately it seems even Netatalk has occasional problems with getting
a connection to a printer.
I do the following:
/usr/bin/pap -p "Laser16/600:LaserFooBar@MyZone" /usr/lib/atalk/pagecount.ps
And normally get:
Trying 100.148:129 ...
status: idle
Connected to Laser16/600:LaserFooBar@MyZone.
*111632
Connection closed.
However today, I consistently kept getting "status: idle", one line after
another, and never got a connection.
This reminded me of what I had seen in the CAP log before, so I tried
browsing the CAP source. Alas this problem seems not to be very well
documented, so if anyone here knows more about this problem I'd appreciate
your input.
What I am interested in finding out is:
Is this a matter of the printer failing to communicate -
Or is it the server software that doesn't handle the communication
correctly. (It seems strange that both CAP _and_ Netatalk and possibly
KASpool get this wrong.)
Other than power-cycling the printer, is there anything that can be done
to bring the printer out of this state?
What is the precise cause that makes the printer enter this state, and
what can be done to prevent it from happening?
-Lasse
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:47 EST