Need to update dirsrv.systemd file

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/48935

• Created at 2016-07-26 22:25:51 by mreynolds (@mreynolds389)
• Closed as Fixed
• Assigned to mreynolds (@mreynolds389)

---

If using systemd, it does not honor the default timeout in the start script of 10 minutes. The default timeout for systemd services is 90 seconds.

Also on Fedora 23+ valgrind doesn't interact well with systemd anymore.

Need to add these lines to /etc/sysconfig/dirsrv.systemd:

TimeoutStartSec=10m   -> set timeout to what we use in our start script
NotifyAccess=all      -> This allows systemd to receive/accept startup/shutdown notifications when using valgrind

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2016-07-27 01:37:43

attachment
0001-Ticket-48935-Update-dirsrv.systemd-file.patch

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2016-07-27 01:45:11

I just would like to learn how the new value 10 min works. I remember we fixed a ticket to shorten the timeout in the startup script which prevented to quit when, e.g., some selinux error occurred. If this change does not bring back the problem, you have my ack. :)

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2016-07-27 02:01:55

Replying to [comment:2 nhosoi]:

I just would like to learn how the new value 10 min works.

This is just sets the timeout when "starting" a service using systemctl

I remember we fixed a ticket to shorten the timeout in the startup script which prevented to quit when, e.g., some selinux error occurred.

We found this issue when valgrind was misbehaving. While the real issue had to do with another systemd setting(NotifyAccess), I thought we should make the timeouts consistent since we were updating the systemd file.

Now there is a timeout of 10 minutes in the start-dirsrv script when waiting for a PID file to be written, but perhaps this is obsolete(including the 10 minute timeout). If I'm correct the pid file is written before we return success/failure.

If this timeout was erroneous to begin with, then what is a good timeout? How long do we wait if a database is being recovered? 90 seconds seems too short in my opinion.

If this change does not bring back the problem, you have my ack. :)

Do you have the steps to reproduce the selinux issue?

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2016-07-27 02:28:53

I think this ticket and the fix mentioned in this ticket was in my mind.

https://fedorahosted.org/389/ticket/48336
Summary: setup-ds should detect if port is already defined

The retry count has been reduced in a recent fix, but retrying makes no sense if it is known to fail again.

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2016-07-27 02:47:16

Replying to [comment:4 nhosoi]:

I think this ticket and the fix mentioned in this ticket was in my mind.

https://fedorahosted.org/389/ticket/48336
Summary: setup-ds should detect if port is already defined

The retry count has been reduced in a recent fix, but retrying makes no sense if it is known to fail again.

Ahh, this is completely different. This issue (ticket 48336) happens internal to DS - it has nothing to do with the systemctl timeout. I also just verified there is no regression with 48336.

Anyway, I leave my patch as it stands (with the 10min timeout).

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2016-07-27 02:50:08

Thank you for your confirmation!
As I wrote in my previous comment, you have my ack. :)

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2016-07-27 02:58:57

Thanks Noriko!

1972195..ce44176 master -> master
commit ce44176
Author: Mark Reynolds mreynolds389@redhat.com
Date: Tue Jul 26 15:31:32 2016 -0400

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2016-07-27 03:00:42

This also impacts 1.3.4

c8e7fc5..5e810f8 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit 5e810f8

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2017-02-11 23:07:52

Metadata Update from @nhosoi:

• Issue assigned to mreynolds389
• Issue set to the milestone: 0.0 NEEDS_TRIAGE

[389-ds-bot]

Comment from vashirov (@vashirov) at 2020-02-12 17:49:31

Metadata Update from @vashirov:

• Issue set to the milestone: None (was: 0.0 NEEDS_TRIAGE)