Bug 1570283

Summary:	Dovecot should use portrelease to avoid port conflicts with NFSv4 mounts
Product:	Red Hat Enterprise Linux 7	Reporter:	Robert Scheck <redhat-bugzilla>
Component:	dovecot	Assignee:	Michal Hlavinka <mhlavink>
Status:	CLOSED ERRATA	QA Contact:	Evgeny Fedin <efedin>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	7.5	CC:	djez, efedin, ovasik, robert.scheck
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	dovecot-2.2.36-4.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-03-31 19:45:54 UTC	Type:	Bug
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:	1570282
Bug Blocks:	1716965

Description Robert Scheck 2018-04-21 14:04:03 UTC

Description of problem:
After rebooting a system I found a non-working dovecot. Some investigation
lead me to this:

[root@tux ~]# netstat -alpen | grep :993
tcp     0    0 192.168.0.29:993     192.168.2.30:2049    TIME_WAIT  0    0    -
[root@tux ~]# 

After umounting my NFSv4 share, I was able to restart dovecot successfully.

Version-Release number of selected component (if applicable):
dovecot-2.2.10-8.el7.x86_64

How reproducible:
Not always, requires some "bad" random after reboot.

Actual results:
Dovecot's ports 993/tcp and 995/tcp might conflicts with NFSv4 mounts.

Expected results:
$ cat /etc/portreserve/dovecot
993/tcp
995/tcp
$ 

$ cat /usr/lib/systemd/system/dovecot.service
…
ExecStartPre=-/sbin/portrelease dovecot
…
$ 

Additional info:
Unfortunately portreserve doesn't seem to work as documented, thus that
issue needs to be addressed first, see bug #1570282 for details.

Comment 2 Robert Scheck 2019-03-22 12:57:45 UTC

Cross-filed case 02344539 in the Red Hat customer portal.

Comment 4 Ondrej Vasik 2019-06-26 07:46:36 UTC

I don't think this can be fixed on dovecot side - and fixing portreserve should fix this. SUNRPC has known disadvantage of randomly assigning rpc ports 665-1023 (well - not completely randomly - it is something like 6XX+pid which results in regular issues with 993/995 ports on certain systems) - thus when NFSv4 is in-place and it has not static ports assigned, it can consume randomly 993/995 port. Solution can be to have static port assigned to nfsv4 or other rpc services. So this can be at least a workaround.

Comment 5 Michal Hlavinka 2019-06-26 08:40:59 UTC

Small correction, the previous comment should probably go to the portreserve bug.
ATM dovecot does not use portreserve, that's why this bug is here, but it will require portreserve to work (that's the other bug).
On the other hand, looking at man bootup, portreserve contains After=sockets.target, Before=basic.target which means that if you enable socket activation for dovecot, those ports should be already reserved by systemd even before portreserve is started.

Comment 9 errata-xmlrpc 2020-03-31 19:45:54 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:1062