Hide Forgot
Description of problem: Enabling RHDS 10.1 instance service on RHEL 7 doesn't work. Administration manual states that to enable instance service is done by running systemctl enable dirsrv@instance_name However, this doesn't survive restart. Searching for enabled units gives: [root@host-172-16-64-130 ~]# systemctl list-unit-files | grep enabled | grep dirsrv dirsrv@.service enabled Version-Release number of selected component (if applicable): RHDS 10 How reproducible: always Steps to Reproduce: 1. create RHDS instance 'abc' 2. run systemctl enable dirsrv@abc 3. restart machine Actual results: dirsrv@abc is not running Expected results: dirsrv@abc is running Additional info: enabling all instances (systemctl enable dirsrv.target) works. Not surre if it's a bug in documentation or sysmted unit files (seems to me more likely). OS: Red Hat Enterprise Linux Server release 7.3 (Maipo) RHDS: redhat-ds-10.1.0-2.el7dsrv.x86_64
Hi Vojtech, could you please provide the version of 389-ds-base? Thanks.
Hi, version of 389-ds-base is 389-ds-base-1.3.5.10-21.el7_3.x86_64 Thanks
This is because of how we structure the unit files. today when you enable dirsrv, it's assigned to the dirsrv.target, and you need to enable that too. IE systemctl enable dirsrv.target systemctl enable dirsrv@instance Really, we should not ship our own target, we should just have our services link to multi-user.target. I think we still need to ship our old target for legacy, but we should change to multi-user.target.
Upstream ticket: https://pagure.io/389-ds-base/issue/49378
Build tested: 389-ds-base-1.3.7.5-6.el7.x86_64 Verification steps: 1. Setup an instance 2. Enable the instance: []# systemctl enable dirsrv@qeos-60 Created symlink from /etc/systemd/system/multi-user.target.wants/dirsrv to /usr/lib/systemd/system/dirsrv@.service. 3. Reboot the machine: []# reboot 4. Check the status: []# systemctl status dirsrv@qeos-60 ● dirsrv - 389 Directory Server qeos-60. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2017-11-03 11:33:36 EDT; 1min 44s ago Process: 1034 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) Main PID: 1052 (ns-slapd) Status: "slapd started: Ready to process requests" CGroup: /system.slice/system-dirsrv.slice/dirsrv └─1052 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-qeos-60 -i /var/run/dirsrv/slapd-q... The instance is active after the reboot. Marking as verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0811