Bug 127174 - "mysterious" failures to start cupsd
"mysterious" failures to start cupsd
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-02 19:18 EDT by Michal Jaegermann
Modified: 2008-04-03 12:58 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-03 12:58:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of 'printconf-tui --Xexport' (2.93 KB, text/plain)
2004-07-03 12:27 EDT, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2004-07-02 19:18:56 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
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
Comment 1 Tim Waugh 2004-07-03 05:38:14 EDT
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.
Comment 2 Michal Jaegermann 2004-07-03 12:27:49 EDT
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!
Comment 3 Tim Waugh 2004-07-05 10:19:37 EDT
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.
Comment 4 Michal Jaegermann 2004-07-05 11:36:19 EDT
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"/>
Comment 5 John Ellson 2005-03-13 08:49:24 EST
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.
Comment 6 Bug Zapper 2008-04-03 11:36:56 EDT
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.

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