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

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

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?

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.

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

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

Thanks Noriko!

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

This also impacts 1.3.4

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

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1994

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.