Bug 223937

Summary: rpc.rquotad grabs port 993 breaking dovecot IMAPs
Product: [Fedora] Fedora Reporter: Doug Mitchell <redhat>
Component: quotaAssignee: Ondrej Vasik <ovasik>
Status: CLOSED DEFERRED QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: fweimer, josip, kdudka, stanis.trendelenburg
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-08 19:58:13 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:
Bug Depends On:    
Bug Blocks: 455859    

Description Doug Mitchell 2007-01-23 05:50:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.0.9) Gecko/20061219 Fedora/1.5.0.9-1.fc6 Firefox/1.5.0.9 pango-text

Description of problem:

RPC rquotad grabs an almost random port at startup, lately on my FC5 server, it has been grabbing TCP/993.  This prevents dovecot secure IMAP from being able to start up because its port is already bound.

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

How reproducible:
Sometimes


Steps to Reproduce:
1. Boot as usual
2. Watch rpc.rquotad grab a random TCP port
3. Watch dovecot IMAPS fail to start

Actual Results:

Dovecot fails to start secure IMAP (IMAP over SSL) on port TCP/993

Expected Results:

IMAP/SSL server should  be running on TCP/993

Additional info:

RPC services should avoid a list of well-know ports when picking a random port to listen on for services that consult the portmapper.

Comment 1 Steve Dickson 2007-01-24 18:55:42 UTC
Yes I agree this is a pain... It happens to all the RPC daemons and 
Unfortunately there is no real easy answer... 

I wonder if added a getservbyport() to the RPC library routines to 
ensure the port is not in /etc/services would help... 

Comment 2 Stanis Trendelenburg 2007-03-19 09:08:31 UTC
I have the same problem here with nfs.statd and dovecot. 

Comment 3 Doug Mitchell 2007-03-20 04:36:58 UTC
How about finding a range of 20-30 "safe" available ports around 800-900 and
having the RPC library try those first.  This would eliminate the common cases.
 Dropping a warning to syslog if it had to pick a random one would also be a
good thing.


Comment 4 Ondrej Vasik 2008-03-02 17:06:52 UTC
*** Bug 435607 has been marked as a duplicate of this bug. ***

Comment 5 Ondrej Vasik 2008-03-12 13:48:18 UTC
Changing version to RAWHIDE as FC-5 is EOL and problem still occurs. The scheme
is following - with RQUOTAD_PORT specified in /etc/sysconfig/nfs quota will try
the port and random port is chosen only if the bind on specified port fails.  

Comment 6 Bug Zapper 2008-05-14 02:33:46 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Kamil Dudka 2008-07-15 08:51:20 UTC
I can't reproduce this behavior. Can anybody attach /etc/sysconfig/nfs and /etc/
services of error-prone installation?

Comment 8 Ondrej Vasik 2008-07-18 14:10:16 UTC
Just want to mention https://bugzilla.redhat.com/show_bug.cgi?id=103401 - very
similar issue (in fact the same, so this one could be easily called duplicate).
Problem is with RPC_ANYSOCK. It is choosing random port between 600 and 1023. So
everything which is in /etc/services in this area should block its port BEFORE
quota is started - and nothing will be broken. The best way to fix the issue
would be to patch glibc to respect /etc/services, but glibc maintainers already
rejected few requests to do that.

Comment 9 Ondrej Vasik 2008-10-08 19:58:13 UTC
Time to make summary:
1) If you specify RQUOTAD_PORT in /etc/sysconfig/nfs and bind on this port is succesful, nothing is broken
2) If not, problem is caused by glibc and will not change ... 
3) Workaround proposed in setup component as bz #455859 - rquotad should be added to /etc/services and the problem should be solved in F10 by portreserve

So I see nothing to do with that bugzilla in quota, closing DEFERRED as it will be workarounded by portreserve in F10 and in F9 by setup and rquotad in /etc/services . If you are not ok with this result, feel free to add comments... but I see no reason to keep it opened.