I guess I had misunderstood the problem.

If the problem is that the /usr/sbin/start-dirsrv etc. scripts do not use systemd, then that is by design.

If the server is installed as a system service, the admin should always use the system provided services for stopping/starting (the service command, the systemctl command). The admin should never use /usr/sbin/start-dirsrv.

So, why then do we even have /usr/sbin/start-dirsrv? For non-root/non-system installs.

Replying to [comment:5 rmeggins]:

I guess I had misunderstood the problem.

If the problem is that the /usr/sbin/start-dirsrv etc. scripts do not use systemd, then that is by design.

If the server is installed as a system service, the admin should always use the system provided services for stopping/starting (the service command, the systemctl command). The admin should never use /usr/sbin/start-dirsrv.

So, why then do we even have /usr/sbin/start-dirsrv? For non-root/non-system installs.

If an admin "accidentally" uses these scripts, then other problems can arise with systemd. Example, "systemctl stop dirsrv", will not work unless it was started with systemctl. Also the docs don't say that admins should "not" use these scripts. This seems like a silly restriction to me; an admin should be able to use these scripts without fear of breaking something. If its not a root user, then it uses the original method anyway.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Shell_Scripts.html#start-dirsrv

IMHO, I would like these scripts to be a robust as possible.

Replying to [comment:6 mreynolds]:

Replying to [comment:5 rmeggins]:

I guess I had misunderstood the problem.

If the problem is that the /usr/sbin/start-dirsrv etc. scripts do not use systemd, then that is by design.

If the server is installed as a system service, the admin should always use the system provided services for stopping/starting (the service command, the systemctl command). The admin should never use /usr/sbin/start-dirsrv.

So, why then do we even have /usr/sbin/start-dirsrv? For non-root/non-system installs.

If an admin "accidentally" uses these scripts, then other problems can arise with systemd. Example, "systemctl stop dirsrv", will not work unless it was started with systemctl. Also the docs don't say that admins should "not" use these scripts.

We should document that the use of these scripts is strongly discouraged, and to use the OS provided commands (like service or systemctl).

This seems like a silly restriction to me; an admin should be able to use these scripts without fear of breaking something. If its not a root user, then it uses the original method anyway.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Shell_Scripts.html#start-dirsrv

IMHO, I would like these scripts to be a robust as possible.

I would like to be able to use these scripts in a non-system/non-root install. The setup scripts do this:
{{{
my $startcmd = "$inf->{slapd}->{inst_dir}/start-slapd";
if ("@systemdsystemunitdir@" and (getLogin() eq 'root')) {
$startcmd = "/bin/systemctl start @package_name@\@$inf->{slapd}->{ServerIdentifier}.service";
}
}}}
@systemdsystemunitdir@ is true if the package was built with explicit systemd support. I think we should use that test instead of @bindir@/systemctl - even if someone did a non-system build but wanted to run as root, without systemd, they could not do that with the @bindir@/systemctl test.

Replying to [comment:7 rmeggins]:

Replying to [comment:6 mreynolds]:

Replying to [comment:5 rmeggins]:

I guess I had misunderstood the problem.

If the problem is that the /usr/sbin/start-dirsrv etc. scripts do not use systemd, then that is by design.

If the server is installed as a system service, the admin should always use the system provided services for stopping/starting (the service command, the systemctl command). The admin should never use /usr/sbin/start-dirsrv.

So, why then do we even have /usr/sbin/start-dirsrv? For non-root/non-system installs.

If an admin "accidentally" uses these scripts, then other problems can arise with systemd. Example, "systemctl stop dirsrv", will not work unless it was started with systemctl. Also the docs don't say that admins should "not" use these scripts.

We should document that the use of these scripts is strongly discouraged, and to use the OS provided commands (like service or systemctl).

Filed doc bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1004430

This seems like a silly restriction to me; an admin should be able to use these scripts without fear of breaking something. If its not a root user, then it uses the original method anyway.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Shell_Scripts.html#start-dirsrv

IMHO, I would like these scripts to be a robust as possible.

I would like to be able to use these scripts in a non-system/non-root install. The setup scripts do this:
{{{
my $startcmd = "$inf->{slapd}->{inst_dir}/start-slapd";
if ("@systemdsystemunitdir@" and (getLogin() eq 'root')) {
$startcmd = "/bin/systemctl start @package_name@\@$inf->{slapd}->{ServerIdentifier}.service";
}
}}}
@systemdsystemunitdir@ is true if the package was built with explicit systemd support. I think we should use that test instead of @bindir@/systemctl - even if someone did a non-system build but wanted to run as root, without systemd, they could not do that with the @bindir@/systemctl test.

New patch being attached...

Revision
0001-Ticket-47500-start-dirsrv-restart-dirsrv-stop-disrv-.patch

git merge ticket47500
Updating 206130a..ba00d48
Fast-forward
ldap/admin/src/scripts/start-dirsrv.in | 18 ++++++++++++++----
ldap/admin/src/scripts/stop-dirsrv.in | 29 ++++++++++++++++++++++++++---
2 files changed, 40 insertions(+), 7 deletions(-)

git push origin master
206130a..ba00d48 master -> master

git push origin 389-ds-base-1.3.1
60cfb73..060c05c 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

commit ba00d48
Author: Mark Reynolds mreynolds@redhat.com
Date: Wed Sep 4 11:43:22 2013 -0400

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/837

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.