Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 223937 - rpc.rquotad grabs port 993 breaking dovecot IMAPs
Summary: rpc.rquotad grabs port 993 breaking dovecot IMAPs
Alias: None
Product: Fedora
Classification: Fedora
Component: quota
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Brock Organ
: 435607 (view as bug list)
Depends On:
Blocks: 455859
TreeView+ depends on / blocked
Reported: 2007-01-23 05:50 UTC by Doug Mitchell
Modified: 2016-04-06 11:18 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-10-08 19:58:13 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 103401 None None None Never

Internal Links: 103401

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: Gecko/20061219 Fedora/ Firefox/ 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):

How reproducible:

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:

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 - 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.

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