+++ 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): 3.2.2 How reproducible: Everytime on my VM host when doing replication. Strange thing is my Master host has the same config files and it starts fine. Additional Info: journalctl shows the following failure: Aug 13 12:45:45 pippin.home.pecknet.com systemd-tmpfiles[191]: Failed to create directory /var/lock/dirsrv: No such file or directory Aug 13 12:45:45 pippin.home.pecknet.com systemd-tmpfiles[191]: 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.
Upstream ticket: https://fedorahosted.org/pki/ticket/743
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) To ssh://vakwetu.org/git/pki.git ebc7bf6..e8d4cb6 DOGTAG_10_0_BRANCH -> DOGTAG_10_0_BRANCH Fixed for 10.1 branch (RA, TPS): To ssh://vakwetu.org/git/pki.git 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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.