Bug 996847 - tmpfiles.d references /var/lock when they should reference /run/lock
tmpfiles.d references /var/lock when they should reference /run/lock
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: pki-core (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthew Harmsen
Fedora Extras Quality Assurance
:
Depends On: 996716 1008306 1008610
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-14 02:53 EDT by Martin Kosek
Modified: 2015-02-18 06:13 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 996716
Environment:
Last Closed: 2015-02-18 06:13:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Kosek 2013-08-14 02:53:32 EDT
+++ 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.
Comment 1 Martin Kosek 2013-09-16 02:17:21 EDT
Hello, any update with this Bug? I think we should fix it scope of F19.
Comment 2 Nathan Kinder 2013-09-16 11:13:07 EDT
(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.
Comment 3 Nathan Kinder 2013-09-16 11:14:28 EDT
Upstream ticket:
https://fedorahosted.org/pki/ticket/743
Comment 4 Mat Booth 2014-10-24 05:31:03 EDT
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?
Comment 5 Matthew Harmsen 2014-10-30 19:15:32 EDT
(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@git.fedorahosted.org/git/pki.git
    
        ebc7bf6..e8d4cb6 DOGTAG_10_0_BRANCH -> DOGTAG_10_0_BRANCH
    
    Fixed for 10.1 branch (RA, TPS):
    
    To ​ssh://vakwetu@git.fedorahosted.org/git/pki.git
    
        64a4b12..a42e510 master -> master
    
Therefore, yes, this fix should exist in Dogtag 10.2.
Comment 6 Fedora End Of Life 2015-01-09 17:35:24 EST
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.
Comment 7 Fedora End Of Life 2015-02-18 06:13:28 EST
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.

Note You need to log in before you can comment on or make changes to this bug.