Red Hat Bugzilla – Bug 996847
tmpfiles.d references /var/lock when they should reference /run/lock
Last modified: 2015-02-18 06:13:28 EST
+++ This bug was initially created as a clone of Bug #996716 +++
Description of problem:
I Setup a replication server and after reboot it fails to start ipa. I did the install three different times and every time I'm able to create the replicaton server but after a reboot it fails to start.
After much digging I finally found out that the /var/lock/dirsrv/slapd-INSTANCE dirs are not being created.
/var/lock is a symlink to /run/lock so I updated the tmpfiles.d to point to /run/lock instead and now ipa starts fine on bootup.
Version-Release number of selected component (if applicable):
Everytime on my VM host when doing replication.
Strange thing is my Master host has the same config files and it starts fine.
journalctl shows the following failure:
Aug 13 12:45:45 pippin.home.pecknet.com systemd-tmpfiles: Failed to create directory /var/lock/dirsrv: No such file or directory
Aug 13 12:45:45 pippin.home.pecknet.com systemd-tmpfiles: Failed to create directory /var/lock/dirsrv/slapd-HOME-PECKNET-COM: No such file or directory
Could be a race condition where /run/lock doesn't exist yet? (That is created from /usr/lib/tmpfiles.d/legacy)
--- Additional comment from Martin Kosek on 2013-08-14 02:24:19 EDT ---
I noticed the "/var/lock" symlinks in dirsrv's tmpfiles config file:
# cat /etc/tmpfiles.d/dirsrv-IDM-LAB-BOS-REDHAT-COM.conf
d /var/run/dirsrv 0770 dirsrv dirsrv
d /var/lock/dirsrv 0770 dirsrv dirsrv
d /var/lock/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM 0770 dirsrv dirsrv
However, is this something that IPA should tackle? It is created during setup-ds.pl phase, by DS. I would expect that DS would update it during upgrade (if necessary). Rich, please advise if this is something that IPA is expected to do.
--- Additional comment from Alexander Bokovoy on 2013-08-14 02:37:37 EDT ---
Similar update to tmpfiles.d needs to be done on Dogtag side as pki-* configs also mention /var/lock and /var/run.
It is worth to file Dogtag bug for that.
As for FreeIPA, we need to avoid running systemd upgrade tool unless we are upgrading from Fedora 16. This needs to be done ASAP.
Hello, any update with this Bug? I think we should fix it scope of F19.
(In reply to Martin Kosek from comment #1)
> Hello, any update with this Bug? I think we should fix it scope of F19.
I agree that we should address this in F19. I have just cloned it to Dogtag's upstream Trac instance, and will triage it for the next Dogtag 10.0.x build.
This looks fixed in the upstream ticket, can I assume this is fixed in F21+ since I have pki-server-10.2.0-3.fc21 there?
(In reply to Mat Booth from comment #4)
> This looks fixed in the upstream ticket, can I assume this is fixed in F21+
> since I have pki-server-10.2.0-3.fc21 there?
Per PKI TRAC Ticket #743:
Fixed in 10.0 branch: (java, RA, TPS)
ebc7bf6..e8d4cb6 DOGTAG_10_0_BRANCH -> DOGTAG_10_0_BRANCH
Fixed for 10.1 branch (RA, TPS):
64a4b12..a42e510 master -> master
Therefore, yes, this fix should exist in Dogtag 10.2.
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.