-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dirsrv fails to start due to incorrect /var/run/lock lines in tmpfiles.d #766
Comments
Comment from rmeggins (@richm) at 2013-07-11 02:31:21 Cannot reproduce - steps
upon reboot, the directory server process is running - /var/run/dirsrv and /var/lock/dirsrv are correctly populated - systemctl status dirsrv@inst.service reports running I did not use IPA - is this perhaps an IPA specific problem? Can you try with plain 389-ds-base? |
Comment from jhogarth at 2013-07-11 19:58:15 I just created a KVM VM - 389dstest.example.com ... Steps I took:
observe /var/lock/ does not have a dirsrv or dirsrv/inst directory and 389ds instance cannot be started... I just tried something else though - manually ran systemd-tmpfiles --create after boot was completed and the /var/lock/* directories are indeed created... I'm beginning to wonder if this is some strange race condition on boot for systemd-tmpfiles when traversing the symlinks (perhaps the double symlink for /var/lock as opposed to the single for /var/run) to the final destination to create the directories. |
Comment from jhogarth at 2013-07-11 20:15:24 Hmm richm can you please close as NOTABUG? After more testing and simplifying of parts I'm sure this is a systemd-tmpfiles issue of some nature ... and I can only intermittently reproduce this with a minimal F19 system and manually putting stuff in /etc/tmpfiles.d without installing anything ... and only on btrfs - ext4 seems fine. I'll look to see if I can reliably get a set of steps in place and file a bug with systemd if I can. |
Comment from rmeggins (@richm) at 2013-07-11 20:29:03 Replying to [comment:2 jhogarth]:
I'm not sure what this means - did you do systemctl enable dirsrv.target?
|
Comment from adamwill at 2013-09-27 09:34:43 jhogarth: did you ever file this? because I seem to be running into exactly this on my newly installed F19 freeipa server, which is a VM. Every time I boot there is no /var/lock/dirsrv, I have these errors in journalctl: Sep 26 20:31:26 id.happyassassin.net systemd-tmpfiles[212]: Failed to create directory /var/lock/dirsrv: No such file or directory and dirsrv fails to start. If I run 'systemd-tmpfiles --create' manually and do 'systemctl restart ipa.service', it starts up successfully. |
Comment from adamwill at 2013-09-27 13:14:24 ab from #freeipa IRC mentioned he also sees this issue sometimes. it's definitely a real problem somewhere. I have disabled ipa.service and done this icky hack to deal with it on my deployment for now: [adamw@id ~]$ cat /etc/rc.d/rc.local It looks like the point where rc.local runs is late enough that this works pretty reliably. At least, it worked twice in a row for me. I call that good. :P To aid anyone else who falls into the same bear trap, there's a problem with simply calling 'systemd-tmpfiles --create': it will create a file /var/run/nologin which will prevent any users other than root from logging into the system (locally or via ssh) with a rather cryptic message: "System is booting up." Any time you see that error, the reason is that /var/run/nologin exists. For this particular scenario, calling "systemd-tmpfiles --create /etc/tmpfiles.d/dirsrv-HAPPYASSASSIN-NET.conf" as listed above will create the dir we want without hitting the directive that creates /var/run/nologin. If anyone winds up here by Googling "System is booting up.": you want to get rid of /var/run/nologin. You're welcome. ;) |
Comment from nkinder (@nkinder) at 2013-09-27 21:44:03 This might be related to a recently fixed issue related to the /var/run symlinks not being created before 389 DS tries to access them on boot. See ticket 47513 for details. |
Comment from adamwill at 2013-09-27 22:17:48 ...which came from https://bugzilla.redhat.com/show_bug.cgi?id=996716 , which I was just pointed at in IRC. This is to ensure anyone showing up to the party late has all the necessary links! |
Comment from salimma at 2013-10-03 12:27:26 This happens to me on two separate F19 FreeIPA installations (one set up to be replica of the other); I'm currently editing /etc/tmpfiles.d/dirsrv-.conf and replacing /var/lock/ with /var/run/* |
Comment from salimma at 2013-10-03 12:37:46 Correction: I had to add this line:
to the configuration file; the two /var/lock entries work fine as they are. Is this the same issue or a different one then? Apologies if I'm mixing things up |
Comment from rmeggins (@richm) at 2013-10-03 20:09:41 Replying to [comment:11 salimma]:
Have you tried the latest Fedora 19 389-ds-base-1.3.1.11 package? It should have fixed this issue. It won't correct existing tmpfiles.d entries but it should create correct tmpfiles.d entries for new instances. |
Comment from adamwill at 2017-02-11 22:49:05 Metadata Update from @AdamWill:
|
Comment from renmare at 2020-06-23 12:19:59 Hello, I'm getting the same issue. This is on CentOS 8 but I suppose it should all be the same. Hoping the following can shed some light, but not really getting any further than this:
Oddly, as @AdamWill mentioned, running
|
Comment from vashirov (@vashirov) at 2020-06-23 14:37:11 @renmare, when does this happen? On reboot or at some other time? Is it consistently reproducible? |
Comment from vashirov (@vashirov) at 2020-06-23 14:37:11 Metadata Update from @vashirov:
|
Comment from renmare at 2020-06-23 22:30:11 Could certainly be. It happens on reboot so it fits, though other items are being mounted work fine:
I've used @AdamWill's workaround and it works fine so again, it fits the race condition. How can fix the issue though? |
Comment from renmare at 2020-06-24 00:55:09 So I've just figured out a better solution that I wouldn't consider hacky. Adding the below line to
One liner:
|
Comment from vashirov (@vashirov) at 2020-06-24 10:14:43 Thank you for testing this and confirming! These conf files are generated during instance creation, so a proper fix would be to change our installer code to use |
Bug Description: systemd-tmpfiles warns about legacy paths in our tmpfiles configs. Using /var/run also introduces a race condition, see the following issue https://pagure.io/389-ds-base/issue/47429 Fix Description: Instead of using @localstatedir@/run use @localrundir@ which was introduced in 389ds#850. Relates: 389ds#766 Fixes: 389ds#4092 Reviewed by: vashirov & firstyear(Thanks!)
Bug Description: systemd-tmpfiles warns about legacy paths in our tmpfiles configs. Using /var/run also introduces a race condition, see the following issue https://pagure.io/389-ds-base/issue/47429 Fix Description: Instead of using @localstatedir@/run use @localrundir@ which was introduced in #850. Relates: #766 Fixes: #4092 Reviewed by: vashirov & firstyear(Thanks!)
Bug Description: systemd-tmpfiles warns about legacy paths in our tmpfiles configs. Using /var/run also introduces a race condition, see the following issue https://pagure.io/389-ds-base/issue/47429 Fix Description: Instead of using @localstatedir@/run use @localrundir@ which was introduced in #850. Relates: #766 Fixes: #4092 Reviewed by: vashirov & firstyear(Thanks!)
Bug Description: systemd-tmpfiles warns about legacy paths in our tmpfiles configs. Using /var/run also introduces a race condition, see the following issue https://pagure.io/389-ds-base/issue/47429 Fix Description: Instead of using @localstatedir@/run use @localrundir@ which was introduced in #850. Relates: #766 Fixes: #4092 Reviewed by: vashirov & firstyear(Thanks!)
Bug Description: systemd-tmpfiles warns about legacy paths in our tmpfiles configs. Using /var/run also introduces a race condition, see the following issue https://pagure.io/389-ds-base/issue/47429 Fix Description: Instead of using @localstatedir@/run use @localrundir@ which was introduced in #850. Relates: #766 Fixes: #4092 Reviewed by: vashirov & firstyear(Thanks!)
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/47429
Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 983073
The text was updated successfully, but these errors were encountered: