Would be possible to add rquotad default port 875 to /etc/services? Due to this absence rpc.rquotad grabs a random port at startup with default configuration. This random port can conflict with known services on ports 600-1023 and causes this services (like secure IMAP) not to start. I am working on patch for glibc/sunrpc which prevent rpc services to grab port of other known services, but modification of /etc/services I found as reasonable first step. +++ This bug was initially created as a clone of Bug #223937 +++ 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. -- Additional comment from steved on 2007-01-24 13:55 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... -- Additional comment from trendele on 2007-03-19 05:08 EST -- I have the same problem here with nfs.statd and dovecot. -- Additional comment from redhat on 2007-03-20 00:36 EST -- 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. -- Additional comment from ovasik on 2008-03-02 12:06 EST -- *** Bug 435607 has been marked as a duplicate of this bug. *** -- Additional comment from ovasik on 2008-03-12 09:48 EST -- 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. -- Additional comment from fedora-triage-list on 2008-05-13 22:33 EST -- 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 -- Additional comment from kdudka on 2008-07-15 04:51 EST -- I can't reproduce this behavior. Can anybody attach /etc/sysconfig/nfs and /etc/ services of error-prone installation?
Hi Kamil. We'll be including portreserve in Fedora 10 with which you can specifically reserve such ports at startup, preventing exactly that behaviour. But of course until thats done i'll just add it to /etc/services for now. Read ya, Phil
Built in rawhide as setup-2.7.4-2.fc11 with rquotad in /etc/services with port 875.
Already fixed in F-9 setup-2.6.17-1.fc9 (marked there temporary - I guess it should be permanent as this is default value for rquotad in nfs package and there are less important services already listed) , closing CURRENT_RELEASE.