Udev & CUPS Problem

Ken Moffat ken at linuxfromscratch.org
Thu Jan 18 14:32:20 PST 2007

On Thu, Jan 18, 2007 at 02:43:31PM -0600, alupu at verizon.net wrote:
> Hi everybody,
> LFS/BLFS system.
> i686-pc-linux-gnu
> CUPS 1.2.7. Parallel printer (garden variety).
> Udev 056 (LFS circa Sept. 2005)
> Works perfectly.
> BTW, by "perfect" here I mean the basic functions work clean and fully:
> - Graphics (Xfree86-4.6)
> - Networking
> - Sound
> - Printing
> (other functions are nice to have but not relevant here).
> Created a replica of the above system on a different drive.
> Obviously, worked identically, but then
> I installed the latest (104) Udev
> (same functionality as 103 except for some "bug fixes") from sources. No other changes/additions/removals.
> To my amazement, I've somehow managed to put together a "clean" new Udev system in spite of the atrocious documentation (especially the lack of coverage of the concept change - elimination  of the 'hotplug', etc.) and support.
> That is, everything works fine and identically as hoped EXCEPT Printing which has been lost completely.

 I think you are saying that you copied the old system, then put in
a new udev ?  Cups-1.2.7 is recent, so which version did you have on
the old system ?  If you had 1.2.7, was it working on the old system
?  If it was, you could mount the other drive somewhere and compare
the cups files and their permissions.
> A few details of the PROBLEM:
> 1. No printing whatsoever (No 'lp/lpr <file>', etc.).

 This might mean you haven't started cups, or else that you haven't
configured it, or (perhaps more likely) that you haven't set a
printer as the *default* (e.g. 'set as default' from 'Manage
Printers' on the cups web page).  I hardly ever use 'lp' nowadays,
almost all my printing is from 'File|Print' dialogues, so I'm not
familiar with how you can make the most of it.  Equally, I wouldn't
attempt to set up cups 1.2 other than by using a browser.

> 2. 'cat <file> /dev/lp0' works OK!.

 That should be enough to tell you that udev is not part of the
problem - unless you have extra rules such as /dev/red-printer' or
/dev/parallel' which are not being obeyed.

> 3. On any attempt to print (other than 'cat' above) the "external" symptom looks like the <file> never "physically" reaches the printer.

 The 'jobs' web page in cups should show something - either the jobs
are waiting in the queue, or else it thinks they have been printed.

 If it thinks they were printed, the access_log and error_log ought
to have *something*.

> 4. The "internals" ('error.log', 'access.log', etc.) do not show any kind of errors, even with 'cups.conf' on "debug2" (it's as if the file never leaves the "queue" - 'lpstat' shows the file sitting there forever; however, the printer _is_ "accepting").

 That displayed status means that the _queue_ is accepting new jobs.
I see you call them 'access.log' etc - on my current build they have
'_' instead of '.' in the names - is it possible you are looking at
old logs from cups-1.1 ?  Also, I have 'cupsd.conf', again maybe a
minor typo but I'd better ask.  Lastly, I've never come accross
'debug2', "LogLevel debug" has provided me with sufficent (and very
verbose) output in earlier versions of 1.2 when I was trying to sort
out a local permissions problem.

> 5. In /dev, "crw-rw---- 1 lp lp 6, 0 lp0" (identical with the original system).

 That just says who can talk to the printer itself, and should be

> 6. Variations thereof:  more permissions, change owner, group) - no cigar.

 How about /var/spool/cups ?  I don't think it's the problem, but I
had a permissions problem there before 1.2 was in blfs and I've
ended up setting /var/spool/cups and its tmp subdirectory to root:lp

> 7. A strange difference between the original (056) and the new (104) system:
> in '/dev' there's no longer a '.udevdb' directory.  Instead, there's a new '.udev' with a 'db' subdirectory containing some wacky symlinks pointing to non-existent targets (but close).
> There's a good chance the clue is here but I can't fathom it.

 I think that is merely an example of how udev has changed.

> 8. Same behavior whether I switch to 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).

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

More information about the lfs-support mailing list