The Wednesday 2005-03-02 at 10:07 +0100, Johannes Meixner wrote:
On Mar 1 21:40 Carlos E. R. wrote (shortened):
What I still don't understand is how the device "/dev/lp0" came to be deleted,
http://lists.suse.com/archive/suse-linux-e/2004-Dec/2640.html
Yes, that explains how to recreate the device file, but that I had already done. What it doesn't explain is why it disappeared - I use the classical static /dev directory, not the other, new, automatic system (udev or whatever is called). The strange thing is that when I asked OO to print, it couldn't, and then I discovered that /dev/lp0 had disappeared. I don't know how that happened, and I'm curious. I certainly did not change any configuration things related to printing before the "failure". It was working, some days later I did some YOU updates, then it failed. Weird.
nor why cups, even after a restart, did not recognize the printer was there again an insisted in not printing.
http://portal.suse.com/sdb/en/2004/05/jsmeix_print-cups-in-a-nutshell.html "The Backends"
Ah... If the data transmission to the recipient fails (usually after several attempts by the backend), the backend will report an error to the print system (more precisely, to cupsd). The backend decides if and how many attempts make sense before it reports that the data transmission has failed. As further attempts would be futile, cupsd disables printing on the affected queue. After eliminating the cause of the problem, the system administrator must reenable printing with /usr/bin/enable. Yes, that was it. :-) But the fact the printer was disabled was not logged to syslog, as far as I could see (and I'm used to read logs). Also, "lpq" complained that "lp is not ready", not "lp is disabled" - the message can be confusing, as it refers to the cups printer or whatever, and not the device port of the same name, as it seemed to me. Command lpr said nothing, as usual. -- Cheers, Carlos Robinson