Bug 487250 - Cups fails because rpcbind is listening on
Cups fails because rpcbind is listening on
Product: Fedora
Classification: Fedora
Component: portreserve (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-02-24 19:35 EST by Bryan Mason
Modified: 2009-03-16 15:49 EDT (History)
2 users (show)

See Also:
Fixed In Version: 0.0.4-1.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-16 15:49:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
CUPS Access Log (7.56 KB, text/plain)
2009-02-24 19:38 EST, Bryan Mason
no flags Details
CUPS Error Log (1.50 KB, text/plain)
2009-02-24 19:39 EST, Bryan Mason
no flags Details
/var/log/boot.log (2.66 KB, application/octet-stream)
2009-02-24 19:47 EST, Bryan Mason
no flags Details

  None (edit)
Description Bryan Mason 2009-02-24 19:35:48 EST
Description of problem:

    In a networked environment, remote printers are not listed by CUPS
    because rpcbind is listening on  Trying to print
    anything from a GUI application or running system-config-printer
    shows no network printers.  Restarting CUPS has no effect.  The
    only solution is to stop CUPS and rpcbind, start CUPS and then
    restart rpcbind.

    Not sure if this is actually a cups problem, but since the result
    is that you can't print, I thought we could start there.

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

    # rpm -q cups portreserve rpcbind

How reproducible:

    Not reproducible yet.  Has occurred twice in the last week.

Steps to Reproduce:

    1. Reboot system.
    2. Try to print something to a network printer.
Actual results:

    No network printers shown.  
    The command "netstat -l -n -p | grep 631" shows:

    # netstat -l -n -p | grep 631
    tcp        0      0     *        
           LISTEN      3091/cupsd          
    udp        0      0       *        
    udp        0      0 :::631                      :::*             

Expected results:

    Network printers should be shown.

Additional info:

    Will attach /var/log/cups/*_log, /etc/cups/cupsd.conf.  Please let
    me know if anything else will help.
Comment 1 Bryan Mason 2009-02-24 19:38:41 EST
Created attachment 333107 [details]
CUPS Access Log
Comment 2 Bryan Mason 2009-02-24 19:39:28 EST
Created attachment 333108 [details]
CUPS Error Log
Comment 4 Bryan Mason 2009-02-24 19:47:59 EST
Created attachment 333111 [details]

Boot log.  Note that portreserve starts _after_ rpcbind:

    Starting rpcbind: [  OK  ]
    Starting NFS statd: [  OK  ]
    Starting RPC idmapd: [  OK  ]
    Starting system message bus: [  OK  ]
    Starting acpi daemon: [  OK  ]
    Starting HAL daemon: [  OK  ]
    Setting network parameters... [  OK  ]
    Starting NetworkManager daemon: [  OK  ]
    Loading autofs4: [  OK  ]
    Starting automount: [  OK  ]
    Starting portreserve: [  OK  ]

Could this be the problem?
Comment 5 Bryan Mason 2009-02-24 20:06:01 EST
OK.  This is weird...

/etc/rc.d/init.d/portreserve contains:

    # portreserve  This script starts and stops the TCP port reserver
    # Originally written by Tim Waugh from Red Hat
    # Adapted to Debian by Javier Fernandez-Sanguino
    # chkconfig: 2345 11 89
    # description: TCP port reservation utility
    # Provides:          portreserve
    # Required-Start:    $network
    # Required-Stop:     $network
    # Default-Start:     2 3 4 5
    # Default-Stop:      0 6
    # Short-Description: Port reservation utility
    # Description:       Portreserve is a TCP port reservation utility
    #                    that can be use to prevent RPC services from 
    #                    picking up well-known reserved ports.

but /etc/rc.d/rc{2,3,4,5}.d/*portreserve contains:

    # ls /etc/rc.d/rc{2,3,4,5}.d/*portreserve
    /etc/rc.d/rc2.d/S28portreserve  /etc/rc.d/rc4.d/S28portreserve
    /etc/rc.d/rc3.d/S28portreserve  /etc/rc.d/rc5.d/S28portreserve

That's not right, is it?
Comment 6 Tim Waugh 2009-02-25 06:25:06 EST
No, it's not.  I had this on my system as well, but running 'chkconfig --add portreserve' (trying to diagnose it) fixed the priorities back to S11 and K89.

I can't see anything wrong with the LSB header, and all the required-start dependencies seem to resolve correctly with the suggested priorities:

portreserve: 11
  required-start: $network
network: 10
  provides: $network
  should-start: iptables ip6tables
iptables: 08
ip6tables: 08

The only thing that seems to be not as it should be is that the cups initscript ought to have 'Should-Start: portreserve' -- but this is no reason for portreserve's start priority to be set as high as 28!

Changing component to chkconfig as it seems to have miscalculated the start/kill priorities.
Comment 7 Bill Nottingham 2009-02-25 17:57:13 EST
NetworkManager (which provides $network for him) started at 27; chkconfig's doing the right thing.
Comment 8 Tim Waugh 2009-02-26 05:18:51 EST
Ah, I should have seen that from comment #4, sorry.

Hmm, seems like portreserve doesn't need to require $network after all then.  Will change.
Comment 9 Fedora Update System 2009-02-26 07:33:49 EST
portreserve-0.0.4-1.fc10 has been submitted as an update for Fedora 10.
Comment 10 Fedora Update System 2009-02-26 10:32:46 EST
portreserve-0.0.4-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update portreserve'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2104
Comment 11 Fedora Update System 2009-03-16 15:49:14 EDT
portreserve-0.0.4-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

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