Bug 223937 - rpc.rquotad grabs port 993 breaking dovecot IMAPs
rpc.rquotad grabs port 993 breaking dovecot IMAPs
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: quota (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Brock Organ
:
: 435607 (view as bug list)
Depends On:
Blocks: 455859
  Show dependency treegraph
 
Reported: 2007-01-23 00:50 EST by Doug Mitchell
Modified: 2016-04-06 07:18 EDT (History)
4 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Doug Mitchell 2007-01-23 00:50:56 EST
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 13:55:42 EST
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 05:08:31 EDT
I have the same problem here with nfs.statd and dovecot. 
Comment 3 Doug Mitchell 2007-03-20 00:36:58 EDT
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 12:06:52 EST
*** Bug 435607 has been marked as a duplicate of this bug. ***
Comment 5 Ondrej Vasik 2008-03-12 09:48:18 EDT
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-13 22:33:46 EDT
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 04:51:20 EDT
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 10:10:16 EDT
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 15:58:13 EDT
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.

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