Bug 1312557 - dirsrv service fails to start when nsslapd-listenhost is configured
Summary: dirsrv service fails to start when nsslapd-listenhost is configured
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-27 10:54 UTC by Viktor Ashirov
Modified: 2016-11-03 20:39 UTC (History)
2 users (show)

Fixed In Version: 389-ds-base-1.3.5.5-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 20:39:50 UTC
Target Upstream Version:


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


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2594 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2016-11-03 12:11:08 UTC

Description Viktor Ashirov 2016-02-27 10:54:33 UTC
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 17:55:10 UTC
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 18:19:30 UTC
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 18:24:22 UTC
(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 18:27:48 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/48747

Comment 7 Viktor Ashirov 2016-08-26 13:30:04 UTC
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 20:39:50 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://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.