Red Hat Bugzilla – Bug 1312557
dirsrv service fails to start when nsslapd-listenhost is configured
Last modified: 2016-11-03 16:39:50 EDT
Created attachment 1131056 [details]
Description of problem:
In some environments network initialization takes a long time (slow DHCP, etc). When nsslapd-listenhost is configured, dirsrv systemd service fails to start, because it doesn't wait for the network to be available (see attached bootchart)
Only dirsrv.target waits for the network.service. To make it more confusing, dirsrv.target reports that it's active, though no instances of dirsrv have been started:
[root@rhel7ds ~]# systemctl status dirsrv.target
● dirsrv.target - 389 Directory Server
Loaded: loaded (/usr/lib/systemd/system/dirsrv.target; enabled; vendor preset: disabled)
Active: active since Sat 2016-02-27 11:35:14 CET; 5min ago
[root@rhel7ds ~]# systemctl status email@example.com -l
● firstname.lastname@example.org - 389 Directory Server rhel7ds.
Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2016-02-27 11:35:14 CET; 5min ago
Process: 728 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i /var/run/dirsrv/slapd-%i.pid -w /var/run/dirsrv/slapd-%i.startpid (code=exited, status=1/FAILURE)
Feb 27 11:35:13 rhel7ds.brq.redhat.com ns-slapd: [27/Feb/2016:11:35:13 +0100] createprlistensockets - PR_Bind() on 172.25.1.3 port 389 failed: Netscape Portable Runtime error -5986 (Network address not available (in use?).)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure nsslapd-listenhost to use external IP address.
2. Disable link on that interface (unplug cable or in case of libvirt VM: virsh domif-setlink $VM_NAME vnetX down)
3. Restart the machine
4. Enable link during the startup when Network Manager waits for the link (that's the tricky part).
dirsrv service fails to start
dirsrv should wait for network.service
diff --git a/wrappers/systemd.template.service.in b/wrappers/systemd.template.service.in
index 629c1ad..3eb0789 100644
@@ -15,7 +15,7 @@
Description=@capbrand@ Directory Server %i.
(In reply to Viktor Ashirov from comment #0)
> Expected results:
> dirsrv should wait for network.service
> Additional info:
> diff --git a/wrappers/systemd.template.service.in
> index 629c1ad..3eb0789 100644
> --- a/wrappers/systemd.template.service.in
> +++ b/wrappers/systemd.template.service.in
> @@ -15,7 +15,7 @@
> Description=@capbrand@ Directory Server %i.
> +After=chronyd.service network.service
This is your proposed fix, right? Could you please open an upstream ticket https://fedorahosted.org/389/newticket and attach this patch (preferably in the git format patch since it could have your name and comments!) to the ticket? I'll ack it there.
Thank you so much!
Created attachment 1131664 [details]
looks like I can't create tickets there:
>TICKET_CREATE privileges are required to perform this operation
I'm attaching patch here. Please replace NNNNN with the ticket number.
(In reply to Viktor Ashirov from comment #3)
> Created attachment 1131664 [details]
> Hi Noriko,
> looks like I can't create tickets there:
> >TICKET_CREATE privileges are required to perform this operation
> I'm attaching patch here. Please replace NNNNN with the ticket number.
> Thank you!
Agh... This is due to the SPAM on the trac, most accounts are closed... :( Could you ask Rich to enable back your account for the future use. In the meantime, I'm going to open an upstream ticket and attach your patch to it.
Created attachment 1194342 [details]
Build tested: 389-ds-base-22.214.171.124-8.el7.x86_64
During the startup dirsrv waits for network. If address is assigned before the
timeout, DS starts up successfully. Otherwise it (rightfully) refuses to start
since there is no address to bind.
Marking as VERIFIED.
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.