Bug 1312557 - dirsrv service fails to start when nsslapd-listenhost is configured
dirsrv service fails to start when nsslapd-listenhost is configured
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Noriko Hosoi
Viktor Ashirov
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-27 05:54 EST by Viktor Ashirov
Modified: 2016-11-03 16:39 EDT (History)
2 users (show)

See Also:
Fixed In Version: 389-ds-base-1.3.5.5-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 16:39:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
bootchart (52.63 KB, image/svg+xml)
2016-02-27 05:54 EST, Viktor Ashirov
no flags Details
0001-Ticket-NNNNN-dirsrv-service-fails-to-start-when-nssl.patch (1.02 KB, patch)
2016-02-29 13:19 EST, Viktor Ashirov
no flags Details | Diff
bootchart-fixed.svg (66.91 KB, image/svg+xml)
2016-08-26 09:30 EDT, Viktor Ashirov
no flags Details

  None (edit)
Description Viktor Ashirov 2016-02-27 05:54:33 EST
Created attachment 1131056 [details]
bootchart

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 dirsrv@rhel7ds.service -l
● dirsrv@rhel7ds.service - 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[728]: [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):
389-ds-base-1.3.4.0-27.el7_2.x86_64

How reproducible:
often

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

Actual results:
dirsrv service fails to start

Expected results:
dirsrv should wait for network.service

Additional info:

diff --git a/wrappers/systemd.template.service.in b/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 @@
 [Unit]
 Description=@capbrand@ Directory Server %i.
 PartOf=@systemdgroupname@
-After=chronyd.service
+After=chronyd.service network.service
 
 [Service]
 Type=notify
Comment 2 Noriko Hosoi 2016-02-29 12:55:10 EST
Hi Viktor,

(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
> b/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 @@
>  [Unit]
>  Description=@capbrand@ Directory Server %i.
>  PartOf=@systemdgroupname@
> -After=chronyd.service
> +After=chronyd.service network.service
>  
>  [Service]
>  Type=notify

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!
Comment 3 Viktor Ashirov 2016-02-29 13:19 EST
Created attachment 1131664 [details]
0001-Ticket-NNNNN-dirsrv-service-fails-to-start-when-nssl.patch

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!
Comment 4 Noriko Hosoi 2016-02-29 13:24:22 EST
(In reply to Viktor Ashirov from comment #3)
> Created attachment 1131664 [details]
> 0001-Ticket-NNNNN-dirsrv-service-fails-to-start-when-nssl.patch
> 
> 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.

Thanks, Viktor!
--noriko
Comment 5 Noriko Hosoi 2016-02-29 13:27:48 EST
Upstream ticket:
https://fedorahosted.org/389/ticket/48747
Comment 7 Viktor Ashirov 2016-08-26 09:30 EDT
Created attachment 1194342 [details]
bootchart-fixed.svg

Build tested: 389-ds-base-1.3.5.10-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.
Comment 9 errata-xmlrpc 2016-11-03 16:39:50 EDT
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://rhn.redhat.com/errata/RHSA-2016-2594.html

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