lib389 remove_ds_instance() does not remove systemd units

[389-ds-bot]

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

• Created at 2018-03-19 14:23:30 by stlaz
• Closed at 2018-04-20 17:31:10 as fixed
• Assigned to spichugi (@droideck)

---

Issue Description

When running remove_ds_instance(), it does not remove the systemd files that identify this instance, namely:

./system/dirsrv.target.wants/dirsrv@INSTANCE.service
./system/multi-user.target.wants/dirsrv@INSTANCE.service

This makes systemd think a DS instance still exist and it also thinks that it can try to start one.

Also, in previous DS versions, the /etc/dirsrv/slapd-INSTANCE would have been moved to /etc/dirsrv/slapd-INSTANCE.removed. This does not happen now. Was this a design decision?

Package Version and Platform

$ rpm -q python3-lib389
python3-lib389-1.4.0.6-2.fc29.noarch

Steps to reproduce

from lib389 import DirSrv
from lib389.instance.remove import remove_ds_instance

ds = DirSrv(verbose=True, external_log=logger)
ds.local_simple_allocate('INSTANCE')
# you have to hack this because DirSrv.local_simple_allocate() won't set serverid
setattr(ds, 'serverid', 'INSTANCE')
remove_ds_instance(ds)

Actual results

# ls -l /etc/systemd/system/multi-user.target.wants/dirsrv@INSTANCE.service
lrwxrwxrwx. 1 root root 39 Mar 12 14:31 /etc/systemd/system/multi-user.target.wants/dirsrv@INSTANCE.service -> /usr/lib/systemd/system/dirsrv@.service
#
# ls -l /etc/systemd/system/dirsrv.target.wants/dirsrv@INSTANCE.service
lrwxrwxrwx. 1 root root 39 Mar 19 12:10 /etc/systemd/system/dirsrv.target.wants/dirsrv@INSTANCE.service -> /usr/lib/systemd/system/dirsrv@.service
#
# ls -l /etc/dirsrv/
drwxr-xr-x. 2 root   root   4096 Mar 12 10:27 config
drwxr-xr-x. 2 root   root   4096 Mar 12 10:27 schema
drwxr-x---. 3 dirsrv dirsrv 4096 Mar 12 16:35 slapd-INSTANCE
drwxr-xr-x. 2 root   root   4096 Mar 12 10:29 ssca

Expected results

The symlinks get removed and the directory moved to *.removed

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2018-04-05 17:44:15

Metadata Update from @mreynolds389:

• Custom field component adjusted to None
• Custom field origin adjusted to None
• Custom field reviewstatus adjusted to None
• Custom field type adjusted to None
• Custom field version adjusted to None
• Issue set to the milestone: 1.4.0

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2018-04-08 01:26:13

Great find! I'll have a look at this soon. If it's urgent, @droideck can probably help :)

[389-ds-bot]

Comment from stlaz at 2018-04-10 14:56:57

I guess it's alright, I'd only like to have freeipa/freeipa#1563 working rather sooner than later but that's just because I like tests passing. It's not going to be in Fedora 28 so it's not critical.
If @droideck wants to have a look, I will most certainly not stand in his way, though!

[389-ds-bot]

Comment from spichugi (@droideck) at 2018-04-18 16:23:32

Metadata Update from @droideck:

• Issue assigned to droideck

[389-ds-bot]

Comment from spichugi (@droideck) at 2018-04-19 14:50:11

Metadata Update from @droideck:

• Custom field reviewstatus adjusted to review (was: None)

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2018-04-20 16:03:28

Metadata Update from @mreynolds389:

• Custom field reviewstatus adjusted to ack (was: review)

[389-ds-bot]

Comment from spichugi (@droideck) at 2018-04-20 17:31:00

5bfc18a..bc181f6 master -> origin/master

[389-ds-bot]

Comment from spichugi (@droideck) at 2018-04-20 17:31:10

Metadata Update from @droideck:

• Issue close_status updated to: fixed
• Issue status updated to: Closed (was: Open)

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2018-04-24 02:57:33

@droideck Hey there. I think there is an issue with your systemctl call. What happens when you run dsctl inst remove twice. You should be able to run the remove as many times as you like safely, to remove the content. I think the current way you have here, if the systemctl isn't there it'll throw an exception perhaps? Can we check this?

[389-ds-bot]

Comment from spichugi (@droideck) at 2018-04-24 09:15:32

Sure, I've checked. We don't have any problem here.
First of all, 'systemctl' return code is 0 even when there is no symlink.

[root@qeos-38 ds]# systemctl disable dirsrv@qeos-38
[root@qeos-38 ds]# echo $?
0
[root@qeos-38 ds]# systemctl disable dirsrv@qeos-38
[root@qeos-38 ds]# echo $?
0

And regarding the twice removal of 'dsctl instance remove', we are also okay:

[root@qeos-38 cli]# ./dsctl standalone1 status
Instance is running
Command successful.
[root@qeos-38 cli]# ./dsctl standalone1 remove --doit

About to remove instance standalone1!
If this is not what you want, press ctrl-c now ...

4 ...
3 ...
2 ...
1 ...
0 ...
Removing instance ...
Completed instance removal
Command successful.
[root@qeos-38 cli]# ./dsctl standalone1 remove --doit
No such instance standalone1

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2018-05-14 05:08:11

Great! Ack from me. Great stuff.