[hpoj-devel] Re: ptal-init start

[upscope <rus...@ce...>]

I welcome your link to the usb printer issue. I have an HP G55 which the
article covers. I have not be able to get it to print even thought the print
manager says it printed successfully. I will go thru the referenced document
and see if that covers my problem I'm using SuSE 9.0 personal edition. The
atricle does mention the G55.
Thanks for your info which may solve my problem. My parellel printer works
fine.

"Johannes Meixner" <js...@su...> wrote in message
news:Pin...@wo......
>
> Hello,
>
> On Apr 13 20:44 Bayard R. Coolidge wrote (shortened):
> >
> > #!/bin/bash
> > /etc/init.d/cups stop
> > /etc/init.d/ptal-init stop
> > /etc/init.d/ptal-init start
> > /etc/init.d/cups start
> >
> > Yes, it's ugly, but it does the trick. I suspect that the problem is
> > that the initialization needs to be done in a specific order, and that
> > the hotplug scripts need to be run before the ptal-init and cups startup
> > scripts during initialization.
>
> See
> http://portal.suse.com/sdb/en/2002/05/ke_hp-officejet.html
> --------------------------------------------------------------------------
> The PTAL service must be started after the USB system and before the
> print service (cupsd or lpd), since the PTAL service requires the
> USB device files /dev/usb/lp* and the printing system requires the
> PTAL device files.
> --------------------------------------------------------------------------
>
> Therefore you may enlarge your script to something like
>
>   #!/bin/bash
>   /etc/init.d/cups stop
>   /etc/init.d/ptal-init stop
>   /etc/init.d/hotplug stop
>   /etc/init.d/hotplug start
>   /etc/init.d/ptal-init start
>   /etc/init.d/cups start
>
> but only if you don't have an imoprtant USB device e.g. an USB keyboard
> because "/etc/init.d/hotplug stop" may disable the USB keyboard.
>
>
> > BTW, if you don't restart cups and ptal as I do in the script and you
> > queue a document for printing first, you'll not only have to run this
> > script, but also go into http://localhost:631/ and Manage Printers to
> > restart your printer.
>
> See
> http://portal.suse.com/sdb/en/2002/05/ke_hp-officejet.html
>
>
> > I'm also finding that I have to restart the print queue using
localhost:631
> > after every document that I print anyway. So, there is clearly a problem
> > with what CUPS is being told or is trying to cope with.
>
> Of course it is clearly not a problem in CUPS but
> - either a problem with the ptal backend
> - or a problem with the ptal backend and the particular printer
> - or a general USB problem (perhaps only on the particular computer
>   or only with the particular printer and the particular computer).
>
> It depends on the particular backend whether or not it gives up or
retries.
> If a backend finishes with non-zero exit code then the cupsd must disable
> the queue.
>
> This is perfectly o.k. because it is the backend (and only the backend)
> which can and must decide whether or not to retry or to tell the cupsd
> that it had finally failed.
>
> It doesn't make sense when a backend gives up with zero exit code
> because this indicates that the job was successfully sent to the
> printer (i.e. the cupsd would remove the job from the spool).
>
> It doesn't make sense when the cupsd doesn't disable the queue
> when a backend results a non-zero exit code because why should
> it work to start with a new job or the same job again.
>
> The only way which makes sense is that
> 1. cupsd disables the queue,
> 2. the user will see (via lpstst or CUPS web interface) that
>    there is a severe problem with the queue,
> 3. the user will inform the administrator,
> 4. the administrator will see (e.g. /var/log/cups/error_log)
>    that it is impossible to send data to the printer,
> 5. the administrator will fix what has caused the problem,
> 6. the administrator will re-enable the queue.
> 7. cupsd will re-send the job
>
> I think that it may be a nice feature to have additional parameters
> for all backends regarding timeout and retries.
>
> For example something like
>   lpd://server/name?timeout=30+retries=0
> to do endless retries.
>
> For example it may make sense to be able to specify something like
>   socket://host:port?timeout=60+retries=1440
> to disable the queue when there is no connection possible within 24 hours.
>
> At the moment the lpd backend has a timeout parameter
> (see for example http://www.cups.org/sam.html#LPD_OPTIONS)
> but no parameter regarding the number of retries.
>
>
> Regards
> Johannes Meixner
> -- 
> SUSE LINUX AG, Maxfeldstrasse 5                 Mail:
js...@su...
> 90409 Nuernberg, Germany                    WWW: http://www.suse.de/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click