Udev & CUPS Problem

Ken Moffat ken at linuxfromscratch.org
Fri Jan 19 04:59:01 PST 2007

On Thu, Jan 18, 2007 at 08:07:17PM -0600, alupu at verizon.net wrote:
> Dan, Ken, Randy:
> Thank you very much for your interest in the subject.
> Unfortunately your comments while very interesting and meaningful haven't helped in moved me any closer to solving the problem.
> Except Dan's "try running strace around the lp call".  I will.
> 1. The kind of system I performed the udev upgrade (056 -> 104)
> An identical, perfect physical replica in _both_ the content and functionality of my good original system.  Long and solidly put through its paces thereafter.

 Ok, so in that case the only changes are udev and copying the
system.  You have the device, with sensible ownership, so I now
think the copy must have done something wrong in the cups
files/permissions.  And I repeat: have a look at the queue on the
cups server to see if it the print is still waiting.

> If that's still confusing, think of it as my having installed udev-104 on my original system (while actually - and fortunately - I still have a perfect "back-up" to go to when I reach a brick wall in trying to troubleshoot this ude104/CUPS-1.2.7 mess).  
> In particular that means that at the upgrade start, CUPS-1.2.7 and udev-056 _must_ have been set-up and configured properly in all respects as having provided me uncounted months of sheer bliss ("Cups-1.2.7 is recent" but not that recent; BTW, I don't remember running into any problem worth mentioning in upgrading from 1.1.23). 

 1.2.7 was announced at cups.org on November 16th, so I think it's
still pretty recent, but I accept you might have been using it for
over a month before you copied the system and upgraded udev.

 And I repeat - mount the old system somewhere, and compare the cups
files (contents of the conf, and permissions).

> While at it, here's a snippet of 'cupsd.conf' file as pertains to one of your comments:
> # LogLevel: controls the number of messages logged to the ErrorLog
> # file and can be one of the following:
> #
> #     debug2    Log everything.
> #     debug     Log almost everything.
> #     info      Log all requests and state changes.
> #     warn      Log errors and warnings.
> #     error     Log only errors.
> #     none      Log nothing.
> #
> LogLevel info

 Nothing like mine - here's the start of my cupsd.conf from 1.2.7

# "$Id: cupsd.conf.in 5454 2006-04-23 21:46:38Z mike $"
#   Sample configuration file for the Common UNIX Printing System
#   (CUPS)
#   scheduler.  See "man cupsd.conf" for a complete description of
#   this
#   file.

# Log general information in error_log - change "info" to "debug"
# for
# troubleshooting...
LogLevel info

# Administrator user group...

 I don't have anything explaining the options, which makes me think
you got your cupsd.conf from an older version.

> 2. If CUPS doesn't work with the good old 'lp/lpr' at the command line, I fail to see how it would work (or can better be tested) from fancier dialogues like "File|Print".
> For the record, I did try to print from graphics like OO-2.03 or AdobeReader-7.08, just for the heck of it.

 Did I say it would work like that?  I said that my_experience is
with using File|Print.  Maybe there is some sort of --pretty-please
switch you could pass to lp/lpr, but I wouldn't know.

 I still don't think udev is the problem, but your mind seems to be
made up about that, so we'll just have to agree to differ.  I've
seen catastrophic udev failures when I tried to upgrade it on a
running system, but every indication is that your new udev is

das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-support mailing list