Bug 132115 - cups deeply confused about its configuration files
Summary: cups deeply confused about its configuration files
Alias: None
Product: Fedora
Classification: Fedora
Component: cups   
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-08 22:41 UTC by Michal Jaegermann
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-30 14:33:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
results of 'printconf-tui --Xexport' (4.62 KB, text/plain)
2004-09-09 15:31 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2004-09-08 22:41:49 UTC
Description of problem:

I tried to add another queue with a printer located on a remote.
Although data which show up in system-config-printer are correct
in /etc/printcap both 'rp' names were reset to names of local
queues, which is very wrong, and 'rm' machines are now set to the
local machine.

The above could be dismissed as simply cosmetics, becase
what is in /etc/cups/printers.conf seems to be roughly sane,
if not that small detail that printing now does not work
at all, on any queue, and I was able to print before messing
up with a configuration.  As usual getting some information
out of this pile of ... is rather hopeless.  Logs in
/var/log/cups/ pretend that nothing happened.

Version-Release number of selected component (if applicable):

How reproducible:
Strange question.  There is always something broken in cups.

Comment 1 Tim Waugh 2004-09-09 08:27:50 UTC
/etc/printcap has not been authoritative for some time.

Need to see 'printconf-tui --Xexport' output to have an idea of the
configuration state.

Comment 2 Michal Jaegermann 2004-09-09 15:31:08 UTC
Created attachment 103642 [details]
results of 'printconf-tui --Xexport'

In the meantime the machine in question was shut down and after it was
brought up again printing on both queues works again.

Yesterday, after changes via 'printconf', the second queue had a big red
cross over it in GUI while jobs sent to the first one were simply vanishing
without any trace and not showing up on a printer - which is even worse.
No amount of mucking around in 'printconf-gui' with "Edit" and "Apply" had
an apparent effect on the situation although I have to admit that I did
not try simple 'service cups restart' (which I would likely do right away
on a non-test installation).

As for /etc/printcap - I realize perfectly well that it is not authoritative
but it could be at least not misleading.  What about a comment:

# this file is full of a random junk

for its entire content?  If that is not enough for some applications then
just a list of colon terminated printer queue names should be sufficient
and better than some crap-shot in fake properties.

BTW - what ate printer aliases?  Do I have to have multiple queues in lieu
of that?  __Big__ PITA in maitenance.

Comment 3 Michal Jaegermann 2004-09-09 17:52:41 UTC
These are experiences after a series of a today updates on x86_64
machine.  After a fresh login 'gnome-printinfo', brought up via
"Print Manager" icon, tells me that I have no printers available
and offers to run a printer configuration tool.  I agree and I am
getting a 'printconfig' window, after a very looong read, with
my only on this box printer queue configured and all data correct.
Without any changes I click, for a good measure, on "Apply" and
that is enough for 'gnome-printinfo' to wake up and recognize
that I have a printer configured after all.  It is even possible
to print on it - which is a nice bonus.

It is possible that glibc updates may have something to do with
the above but one would expect a printer daemon still function.

Comment 4 Tim Waugh 2004-09-09 17:56:35 UTC
What does this say?:

/sbin/chkconfig --list cups

Comment 5 Michal Jaegermann 2004-09-09 18:27:28 UTC
/sbin/chkconfig --list cups
cups     	0:off	1:off	2:on	3:on	4:on	5:on	6:off

Comment 6 Michal Jaegermann 2004-09-09 18:53:04 UTC
And here is more fun courtesy of the whole printing setup.
I noticed that a small new icon showed up on my toolbar.  After
squinting on it for a while it looked like a printer.  Clicking
on it opened a window with a "Document print status" title.
It has one line in it which says:

Unknown  lp   ?   1 hour and 5 minutes ago   Unknown

This apparently refers to my test print job which I did after
I managed to get my printer back in action and which finished
in about that time.  "Edit" on that line offers options like
"Cancel Documents", "Pause Documents", "Resume Documents".
Regardless of what I am choosing and what I do in the followup
that does not seem to have any effect whatsoever.  'lpq' says:

lp is ready
no entries

and 'lpc' agrees with it.  Now what?

Comment 7 Tim Waugh 2004-09-10 08:17:26 UTC
Please stop adding more bugs into the same report.

Let's stick to the bug you first reported: queues stopped working. 
File the others into separate reports, since they are for separate

Comment 8 Michal Jaegermann 2004-09-10 15:52:24 UTC
I am not really sure what the issues really are but if you prefer
I will re-file some comments as separate reports.

Comment 9 Matthew Miller 2006-07-10 21:29:27 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Comment 10 John Thacker 2006-10-30 14:33:08 UTC
Closing per lack of response to previous request for information.
Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

Note You need to log in before you can comment on or make changes to this bug.