Bug 154800

Summary: listen(995) failed: Address already in use
Product: [Fedora] Fedora Reporter: Ralf Corsepius <rc040203>
Component: dovecotAssignee: John Dennis <jdennis>
Status: CLOSED DUPLICATE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 3CC: jss, tss, wtogami
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: 2005-07-29 14:03:28 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Ralf Corsepius 2005-04-14 06:03:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Fedora/1.7.6-1.3.2

Description of problem:
When rebooting, dovecot occasionally fails for me with this error message:

Apr 14 11:12:14 mccallum dovecot: Fatal:
Apr 14 11:12:14 mccallum dovecot: listen(995) failed: Address already in use
Apr 14 11:12:14 mccallum dovecot: dovecot startup failed

Checking netstat reveils that starting dovecot fails because port 995/pop3s already is occupied by ypserv.

IIRC, ypserv uses dynamicially assigned ports, which could indicate that ypserv is started too early during boot-up, rsp. that dovecot must be started before ypserv.


Version-Release number of selected component (if applicable):
dovecot-0.99.13-3.FC3

How reproducible:
Sometimes

Steps to Reproduce:
bootup a server which uses ypserv and dovecot (a server hosting yp/nis and email) 

Actual Results:  dovecot doesn't start up.


Expected Results:  Proper startup.

Additional info:
Comment 1 Jeremy Sanders 2005-06-15 04:47:36 EDT
I see in

https://www.redhat.com/archives/fedora-list/2005-January/msg04804.html

that you may be able to add a -p PORT line to the ypserv command line. I think
something like

YPSERV_ARGS=-p 900

in /etc/sysconfig/network may fix this problem (if other rpc programs don't get
there first). I haven't tried this out on our server with this problem yet.

RedHat/Fedora should probably set the programs which dyanamically assign rpc
ports to fixed locations by default (or a sensible range of ports), to prevent
this random failure.
Comment 2 Jeremy Sanders 2005-06-16 09:30:20 EDT
Looking at the source for ypserv, the appropriate section is

  else
    my_socket = RPC_ANYSOCK;

  transp = svcudp_create (my_socket);
  if (transp == NULL)
    {
      log_msg ("cannot create udp service.");
      exit (1);
    }

So, it looks to be a glibc issue. Shouldn't glibc avoid using ports that are
defined in the /etc/services file?
Comment 3 John Dennis 2005-07-28 17:34:57 EDT
Jeremy's observation in comment #2 about glibc components avoiding ports in
/etc/services seems valid to me so I'm assigning this to Jakub. However, in
fairness I don't think the imap ports were added to the setup rpm (which
contains /etc/services) until version setup-2.5.34-1 on Sept 23 2004. I'm not
100% sure which rpm the secure pop/imap ports made their debut in but the point
is it wasn't that long ago, so perhaps glibc is correctly avoiding ports defined
in /etc/services but the SSL imap ports were absent in the version of the file
where this occurred. But I think Jakub can quickly answer whether /etc/services
ports are sacrosanct.
Comment 4 Jakub Jelinek 2005-07-28 17:43:40 EDT
glibc (bindresvport in particular) intentionally doesn't skip any /etc/services
ports, because almost all are reserved for something and some sunrpc users like
nfs mounting need sometimes hundreds of the reserved ports.
See e.g. #154678 for details.  The fact that some port is listed in /etc/services
doesn't mean it will be actually used for that service on this box, in fact
usually it does not.  So, either the boot sequence makes sure services that
need the fixed reserved ports are started before those using bindresvport,
there should be a deamon (or initscripts itself) that is told about what
ports will all services it is going to start need and reserve the ports for them
early and then pass them over to the daemons.
Comment 5 John Dennis 2005-07-29 14:03:28 EDT
After a bit of investigation I discovered this is a well known problem (bug
#103401) with a solution (see that bug report). I'm marking this as a duplicate
of 103401 and I'll volunteer to take ownership of the portresve package if we
can get agreement to put it in the distribution.

*** This bug has been marked as a duplicate of 103401 ***
Comment 6 Ralf Corsepius 2005-07-29 15:17:56 EDT
(In reply to comment #5)
> After a bit of investigation I discovered this is a well known problem (bug
> #103401) with a solution (see that bug report). I'm marking this as a duplicate
> of 103401 and I'll volunteer to take ownership of the portresve package if we
> can get agreement to put it in the distribution.

I do not agree. IMO, the solution is that mentioned in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103401#c1
which would mean a major redesign of the initscripts.
Comment 7 John Dennis 2005-07-29 15:36:07 EDT
It's not a major redesign, its a matter of adding one line to invoke
portrelease, that doesn't sound very complicated (and requiring the installation
of the portreserve package).

Since there is a strong resistence to modifying glibc (see Jakub and Ulrich's
comments) and has been pointed out in several comments there is a cyclical
dependency on initscript ordering then please offer a better solution that has a
consensus for adoption.

I think Tim's portrelease has the potential for a race condition, but at the
moment it seems very low risk.

Also I think portrelease needs to be modified to persist to reclaim a reserved
port if the service shuts down in the initscript, that would make two lines in
the initscript that needs to be added, one in start() and one in stop().
Comment 8 Ralf Corsepius 2005-07-29 15:44:20 EDT
(In reply to comment #7)

> Since there is a strong resistence to modifying glibc (see Jakub and Ulrich's
> comments) and has been pointed out in several comments there is a cyclical
> dependency on initscript ordering then please offer a better solution that has a
> consensus for adoption.
Counter question: How do other OSes (BSD, Solaris) and Linux distributions
(Debian, SuSE) solve this issue? Esp. knowing what SuSE does would be
interesting, because they dynamically assign initscript priorities.

As portmap, yp* etc. are widely used on various OSes, as this problem is not new
(> 15 years), I would be surprised if there wasn't a commonly accepted solution. 
Comment 9 Denis Pugnere 2006-08-23 11:48:23 EDT
(In reply to comment #8)

I had this problem (631 port reservation) between cups and ypbind, then I
contacted Thorsten Kukuk.
I don't speak on behalf of suse, but Thorsten Kukuk (ypbind maintainer) told me
in a message that :
 "(suse) have a blacklist of which ports RPC based programs are not allowed to use."

In RHEL 4, the upbind man page is false, the upbind has a "-p" parameter witch
allow to bind it to a specific port.

denis