#47500 start-dirsrv/restart-dirsrv/stop-disrv do not register with systemd correctly
Closed: Fixed None Opened 6 years ago by mreynolds.

"systemctl" should be used when start/restart/stop the server.

The current scripts don't register the process correctly(systemd-cgls):

├─user.slice
│ └─user-0.slice
│ ├─session-2.scope
│ │ ├─1153 sshd: root@pts/1
│ │ └─1156 -bash
│ └─session-1.scope
│ ├─ 1122 sshd: root@pts/0
│ ├─ 1127 -bash
│ ├─26382 ./ns-slapd -D /etc/dirsrv/slapd-ibm-x3650m4-01-vm-08 -i /var/run/dirsrv/slapd-ibm-x3650m4-01-vm-08.pid -w /var/ru

It should be under the system slice:

└─system.slice
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─system-dirsrv.slice
│ └─dirsrv@ibm-x3650m4-01-vm-08.service
│ └─32293 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-ibm-x3650m4-01-vm-08 -i /var/run/dirsrv/slapd-ibm-x3650m4-01-vm-08.pid -w /var/run/dirsrv/slapd-ibm-x3650m4-01-vm-08.startpid


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

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

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.1.8

2 years ago

Login to comment on this ticket.

Metadata