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 revealed: 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, Listen 192.168.23.193:631 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: lp|lp:rm=dyna0.home.front:rp=lp: 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): cups-1.1.21-1.rc1.2 How reproducible: Always
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. Thanks.
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!
Thanks. There are three unrelated issues here, so I'll go through them one at a time. 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 right place. 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 /etc/cups/cupsd.conf. 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 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127174#c3 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 @@ </foomatic_defaults> </filter_data> <filter_type TYPE="STRING" VALUE="MAGICFILTER"/> + <sharing ANONYMOUS="TRUE" TYPE="LIST"> + <hosts1 TYPE="STRING" VALUE="192.168.23.0/255.255.255.0"/> + </sharing> <jobsheets TYPE="LIST"> <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 at 192.168.0.14. 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.