RE: [hpoj-devel] ptal-mlcd and hotplug scripts

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Allen Barnett wrote:
> I "fixed" this problem by commenting the 'checkpc' command out of the
> lpd init script. There's definitely a race condition between the
> execution of the runlevel init scripts and the startup of the 
> kernel USB
> hub daemon and the subsequent execution of hotplug scripts; the kernel
> printer module may not even be loaded when the lpr init 
> script executes.
That's one way to fix the problem, but I don't want to require users to
perform that level of hacking to get things to work.

> So, starting and stopping ptal-printd should probably be the
> responsibility of the printing system, not the hotplugging system. Can
> one ptal-printd process tolerate the stopping and restarting of
> ptal-mlcd?
I think it can as long as it doesn't have an open connection to ptal-mlcd.
If it does then it will probably die from a broken-pipe signal when it tries
to write more data to the socket.  Thanks for asking this question and
making me realize this problem, which is now on my TODO list to fix.

> OTOH, how about adding the ability of ptal-mlcd to execute a 
> script when
> it starts and stops? It  could start and stop ptal-printd and 
> enable and
> disable print queues and so on. 
I thought about that, but dynamically creating and deleting print queues
could prove to be rather difficult, given the variety of print systems out
there.  One possibility would be to have "template" queues, where the device
node is set to /dev/null and an indication its target device (PTAL device
name or USB vendor/product IDs) could be encoded into the queue name.
ptal-mlcd could invoke a sub-hotplug script that would start ptal-printd and
then copy the template queue into an actual queue for that device.  Unplug
might not be as reliable, though, because ptal-mlcd could crash or be killed
without having a chance to run the "shutdown" script (which would somehow
kill ptal-printd and remove the hotplugged-device queue).  Another problem
with this scheme is that lpd (or whatever) would probably need to be
restarted after mucking around with /etc/printcap, and this might upset a
pending print job on another queue.  An init script would also need to be
run at startup before LPRng in case the system crashed and there are
leftover hotplug queues.  So in any case, I think there are a lot of holes
that would need to be plugged in this scheme before it's feasible.

David