Udev & CUPS Problem
alupu at verizon.net
alupu at verizon.net
Thu Jan 18 18:07:17 PST 2007
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.
Going over your comments I realized that my original description was more confusing than useful in many respects (blame space constraints and my rambling style).
I'll remake a few points, to answer your concerns in a hopefully more explicit way.
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.
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).
Yes, CUPS (1.2.7) might be tricky and "dodgy", but as I said, had worked without problems, and played no part whatsoever in my Udev upgrade. No CUPS files, directories, permissions, etc. were touched in any way, directly or indirectly. Even on the new system, it comes up (during boot) just fine and in the proper sequence (toward the end of the boot scripts, i.e., long after the udev-"coldplugging" had settled down).
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.
As I mentioned, in hopes of tracking down the problem, I revved up 'cupsd' at times from the default "info" all the way to "debug2" at the risk of blowing up the machine :-). Unfortunately, not a hint of error or any difference in logging output from when it worked in udev-056, before the installation work on udev-104.
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.
3. 'cat <file> /dev/lp0' works OK!.
"That should be enough to tell you that udev is not part of the problem.
Also, same behavior whether you switch to 188.8.131.52 and/or build 'lp' as a module or in the kernel."
"Again, it indicates that udev (and modprobe) are not implicated in the problem ;-) I suppose that asking about udev itself on lfs-support is fair enough, but printing problems really belong on blfs-support even if they are caused by udev (or, more realistically, the rules)."
I did use LFS's latest rules ("udev-config-20061021") on the 104 system (as I was supposed to). As an aside, the explanatory text files of that package are the only bright spot in the new udev documentation and support. Thanks.
_Everything other than printing works_ on the 104 system (identically to the original system) so the rules as applicable to my system _must_ be working (see, for example, the resulting "crw-rw---- 1 lp lp 6, 0 lp0" - and variations tried).
No matter how you cut it, the new Udev must be at the core of the problem.
Think of it this way. I have a perfectly functional system with applications A to Z running on it just fine. I install/upgrade application U without conscientiously touching anything else (i.e. I did it "by the U book"), and all of a sudden the good application C no longer works while all the other still run fine. No common files/permissions that I know (or should know) of.
More information about the lfs-support