#49612 lib389 remove_ds_instance() does not remove systemd units
Closed: wontfix 4 years ago Opened 4 years ago by stlaz.

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


Metadata Update from @mreynolds:
- 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

4 years ago

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

I guess it's alright, I'd only like to have https://github.com/freeipa/freeipa/pull/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 @spichugi wants to have a look, I will most certainly not stand in his way, though!

Metadata Update from @spichugi:
- Issue assigned to spichugi

4 years ago

Metadata Update from @spichugi:
- Custom field reviewstatus adjusted to review (was: None)

4 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to ack (was: review)

4 years ago

Metadata Update from @spichugi:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

4 years ago

@spichugi 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?

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

Great! Ack from me. Great stuff.

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

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.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

2 years ago

Login to comment on this ticket.

Metadata