Bug 1476207
| Summary: | Enabling instance service doesn't work | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Vojtech Juranek <vjuranek> |
| Component: | 389-ds-base | Assignee: | mreynolds |
| Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
| Severity: | unspecified | Docs Contact: | Marc Muehlfeld <mmuehlfe> |
| Priority: | low | ||
| Version: | 7.3 | CC: | atolani, nkinder, rmeggins, spichugi |
| Target Milestone: | pre-dev-freeze | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 389-ds-base-1.3.7.5-5.el7 | Doc Type: | Bug Fix |
| Doc Text: |
The *dirsrv@.service* meta target is now linked to *multi-user.target*
Previously, the *dirsrv@.service* meta target had the "Wants" parameter set to "dirsrv.target" in its systemd file. When you enabled *dirsrv@.service*, this correctly enabled the service to the *dirsrv.target*, but *dirsrv.target* was not enabled. Consequently, Directory Server did not start when the system booted. With this update, the "dirsrv@.service" meta target is now linked to *multi-user.target*. As a result, when you enable *dirsrv@.service*, Directory Server starts automatically when the system boots.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-10 14:19:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Vojtech Juranek
2017-07-28 09:47:12 UTC
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 |