Bug 85149

Summary: rpc.rquotad can grab tcp port 631 (ipp) needed by cups.
Product: [Retired] Red Hat Linux Reporter: Ian Mortimer <i.mortimer>
Component: quotaAssignee: Steve Dickson <steved>
Status: CLOSED DUPLICATE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: mitr
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-05-16 15:52:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ian Mortimer 2003-02-26 00:40:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
Not sure if this is a problem with the rquotad server or elsewhere in the rpc
code (glibc?).  After a reboot of an nfs and print server for a small network,
cups failed to start because rpc.rquotad was already using tcp port 631 (ipp).

I reproduced this on a non-production box like this:

   while : ; do service nfs restart; rpcinfo -p | grep -qw 'tcp *631' && break; done

Eventually rpc.rquotad got tcp port 631.

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


How reproducible:
Sometimes

Steps to Reproduce:
1.Stop cups
2.restart nfs repeatedly as shown above
3.check rpc ports with rpcinfo -p
    

Actual Results:  rpc.rquotad grabs tcp port 631 which will stop cups from starting.

Expected Results:  No rpc services should use port 631 since it is required by cups.

Additional info:

nfs starts before cups (by default) which means that randomly cups will fail to
start on a box which is both an nfs server and a cups server.

Comment 1 Tim Waugh 2006-05-16 15:52:52 UTC

*** This bug has been marked as a duplicate of 168996 ***