Bug 132890 - cupsd mysteriously affected by other updates
Summary: cupsd mysteriously affected by other updates
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-09-18 20:49 UTC by Michal Jaegermann
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-12-06 12:57:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2004-09-18 20:49:53 UTC
Description of problem:

After a set of updates to 'rpmdb-fedora-2.91-0.20040918' and
a reboot I got:

Starting cups: cupsd: Child exited with status 98!
                                                           [FAILED]

"Manual" attempts of 'service cups start' had the same effect.

On a desktop I am told by "Printer Manager" that I have no
printers, of course, but when a configuration is opened my
printer queue is there and after some null "edits" and "Apply"
cups service is running and restarts.  Of course all attractions
described in bug #132288 are still there.

I got the same on another machine (x86 as opposed to x86_64) but
forewarned I saved a copy of /etc/cups/cupsd.conf before
configuration edits.  Here is a diff from that exercise:

@@ -426,7 +426,6 @@
 
 #Port 80
 #Port 443
-Port 631
 
 #
 # HostNameLookups: whether or not to do lookups on IP addresses to get a

Eh???  Of course something else could changed as well.  With
a "black box" approach of GUI tools I cannot even start guessing
what.

Version-Release number of selected component (if applicable):
cups-1.1.21-1.rc2.1

Comment 1 Tim Waugh 2004-12-03 17:10:59 UTC
Did you edit /etc/cups/cupsd.conf?  You don't need a Port directive.

Comment 2 Michal Jaegermann 2004-12-04 02:19:24 UTC
No, I did not edit.  This was from a diff with a version of cupsd.conf
which was showing up with an updated package.  There were also lines
below "Do not EDIT" and some other thing but that was the only one
piece which looked remotely relevant.

I found in the meantime that cupsd from time to time likes to go
into a deep funk and apparently then the only way around is to
"configure" the thing, do not really change anything, "apply changes"
and then it behaves. I did not try to investigate what it is really
doing during such sequence.

Comment 3 Tim Waugh 2004-12-06 12:57:45 UTC
system-config-printer always removes "Port" lines from cupsd.conf when it
adjusts it.

When cups is updated:

* if system-config-printer has already configured cupsd.conf, a
cupsd.conf.rpmnew is created which is self-consistent (i.e. doesn't have
conflicting "Port" and "Listen" directives)

* if cupsd.conf was not altered, it is replaced

So the only way I can see cupsd.conf getting a "Port" directive that conflicts
with the "Listen" directives that system-config-printer writes is if the .rpmnew
file is manually merged into the cupsd.conf file.

Can you reproduce this behaviour, and if so which versions are installed before
upgrading and which versions afterwards?

Comment 4 Michal Jaegermann 2004-12-06 17:12:40 UTC
> ... cupsd.conf.rpmnew is created

You were seeing what looked as "significant" differences between
old cupsd.conf and cupsd.conf.rpmnew; IIRC as this was few months
ago when I filed that bug and I may be fuzzy on details.

> Can you reproduce this behaviour

When the next update of cups will show up I will try to see more
carefully again what is happening.  In the meantime I "reconfigured"
cups so many times that I stopped paying attention.


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