Red Hat Bugzilla – Bug 127174
"mysterious" failures to start cupsd
Last modified: 2008-04-03 12:58:22 EDT
Description of problem:
Recently I started getting the following messages from cups during
a machine startup:
"cupsd: Child exited with status 99"
and, of course, FAILED and no other indication to a true nature
of the problem. Only bringing strace into a fray eventually
EADDRNOTAVAIL (Cannot assign requested address)
Now /etc/cups/cupsd.conf contains this threatening line:
# Lines below are automatically generated - DO NOT EDIT
and below it, among other things,
which indeed is not what I have put there myself. Here is the
rub: my test machine is on DHCP and currently got a different
address than 192.168.23.193. I do not happen to have DDNS but
on a full scale installation - why not? Am I supposed to edit
this "DO NOT EDIT" stuff every time things will change? Clearly
cups is not doing that by itself.
What is more after correcting the above and restarting cupsd
/etc/cups/printers.conf actually now points to an
lpd printer on another machine with a fixed address (which is
correct) but /etc/printcap says that it was "automatically
generated by cupsd(8) from the /etc/cups/printers.conf" and
has the following line in it:
which _does not_ correspond to what is in /etc/cups/printers.conf.
'dyna0.home.front' is not mentioned in printers.conf
anywhere; neither by name nor by IP. 'dyna0.home.front' happens
to be the current name of the host with /etc/printcap on it
so this "rm" does not look right even if it not really used.
Taking into account that in no time a local printer was configured
on a test box, but always a remote, this "Listen" line in
/etc/cups/cupsd.conf is even stranger.
Version-Release number of selected component (if applicable):
Could you please attach the output of 'printconf-tui --Xexport',
making sure to edit out any passwords it contains? I want to be sure
about the cause of this.
Created attachment 101613 [details]
output of 'printconf-tui --Xexport'
I guess that the troublesome 'Listen' directive was inherited from the previous
version (cups update was installed very recently) and was associated with
"Shared" property; which also got somehow "inherited" and never explicitely set
by me. It vanished when I turned off "shared" and was replaced by
"Listen *:631" when I turned that back on. But when I tried to limit sharing
to a given subnetwork then again a specific IP address got into that
directive while this indeed could be a print server, referenced from clients
by its name, and a Dynamic DNS in use.
/etc/printcap in all cases has a local machine in 'rm=...'. Ugh!
There are three unrelated issues here, so I'll go through them one at
1. Printcap contents
Okay, 'dyna0.home.front' in this case is the name that cupsd decided
to use instead of 'localhost' -- it does not refer to the remote
queue, but the local CUPS server. And technically, it *is* right
since submitting a job to 'lp' on that machine will end up at the
The contents of /etc/printcap are informational only. I'm not sure
why it doesn't use 'localhost', but in any case you can configure the
string it puts there by adjusting the ServerName variable in
2. Listen directives not being updated for dynamic address changes
Yes, this limitation is known about but not yet addressed.
3. Listen directives appearing in the first place
I'm not clear about when you exported the configuration data you
attached -- can you clarify it please? Did you change a setting
before exporting and attaching it?
It sounds, from what you're saying, as though a queue became
automatically set to be available for other computers to use without
your explicit say-so -- this is not meant to happen.
These refer to
Ad 1. Changing a name of a local printer indeed is changing
a name used by ':rp=...'; but this is a very stretched interpretation
to make that "technically correct". Is this truly broken model one
of reasons why lpq is shot? See bug #90619. The later is a real
BIG PAIN on an installation with a busy printer and many clients.
Ad 3. I experimented with configurations before I got a request
for a 'printconf-tui --Xexport' output. The one attached is from
a situation when "Shared" property was explicitely turned off.
Here is the only real difference between that and a situation when
sharing is on but explicitely limited to a local network (and when
a troublesome "Listen" with a specific address shows up again):
@@ -44,6 +44,9 @@
<filter_type TYPE="STRING" VALUE="MAGICFILTER"/>
+ <sharing ANONYMOUS="TRUE" TYPE="LIST">
+ <hosts1 TYPE="STRING" VALUE="192.168.23.0/255.255.255.0"/>
<start TYPE="STRING" VALUE="none"/>
<end TYPE="STRING" VALUE="none"/>
I seem to have a related problem: my cupsd also dies with "Child
exited with status 99!"
I have two 10/100 interfaces on my MB, and one died recently, so I
have the dead eth0 at 192.168.0.13 with onboot=no, and the live eth1
Somebody keeps ifup'ing eth0 which may be another problem.
After reading above I discovered that /etc/cupsd.conf had "Listen
192.168.0.13:631" in it, who put that in there?
Removing that line allows cups to start.
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.