When running remove_ds_instance(), it does not remove the systemd files that identify this instance, namely:
remove_ds_instance()
./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?
/etc/dirsrv/slapd-INSTANCE
/etc/dirsrv/slapd-INSTANCE.removed
$ rpm -q python3-lib389 python3-lib389-1.4.0.6-2.fc29.noarch
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)
# 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
The symlinks get removed and the directory moved to *.removed
*.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
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
Metadata Update from @spichugi: - Custom field reviewstatus adjusted to review (was: None)
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to ack (was: review)
5bfc18a..bc181f6 master -> origin/master
Metadata Update from @spichugi: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
@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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.