Description of problem: The lock directory is now symlinked to /var/run which is on tmpfs. The tmpfiles.d configuration that dirsrv puts in place (see a similar bug #857939 but that was for /var/run/dirsrv and not /var/lock being moved to /var/run/lock) specifies the old location of /var/lock/dirsrv and /var/lock/dirsrv/slapd-EXAMPLE-COM but systemd-tmpfiles does not follow the symlink so the directory never gets created and has to be created by hand. Version-Release number of selected component (if applicable): 389-ds-base-1.3.1.3-1.fc19.x86_64 How reproducible: Every time Steps to Reproduce: 1. Clean install of F19 2. Install 389-ds (I used freeIPA to speed up the process and developing against freeIPA is where I bumped into this). 3. Observe dirsrv starts fine. 4. Reboot system 5. Observe dirsrv fails to start 6. Add lines to /etc/tmpfiles.d/dirsrv-EXAMPLE-COM.conf to create /var/run/lock/* instead of /var/lock/* 7. Reboot system 8. Observe right directories are created and dirsrv instance runs Actual results: dirsrv fails to start after a reboot Expected results: dirsrv starts with no manual intervention
Upstream ticket: https://fedorahosted.org/389/ticket/47429
For the record, I am seeing this with a newly-deployed F19 freeipa server, happened to me at least five or six boots in a row, I never got a 'successful' boot. And 'ab' from #freeipa on freenode says he sees it on his deployment too.
*** This bug has been marked as a duplicate of bug 996716 ***