Steps to Reproduce: 1. Do a fresh install of beaker-server on RHEL7 2. systemctl start beakerd Actual results: Fails to start because it can't write its pid file: Apr 14 07:28:31 beaker01.qa.fedoraproject.org systemd[1]: Starting Beaker scheduler... Apr 14 07:28:33 beaker01.qa.fedoraproject.org systemd[1]: PID file /var/run/beaker/beakerd.pid not readable (yet?) after start. Apr 14 07:28:33 beaker01.qa.fedoraproject.org systemd[1]: beakerd.service never wrote its PID file. Failing. Apr 14 07:28:33 beaker01.qa.fedoraproject.org systemd[1]: Failed to start Beaker scheduler. Apr 14 07:28:33 beaker01.qa.fedoraproject.org systemd[1]: Unit beakerd.service entered failed state. Apr 14 07:28:33 beaker01.qa.fedoraproject.org systemd[1]: beakerd.service failed. Expected results: should start Additional info: /var/run/beaker won't exist. We ship a tmpfiles.d config to create it, but it's never invoked when the package is freshly installed. This is some kind of packaging bug, as in we should probably be invoking systemd-tmpfiles in RPM %post or something, but I can't find any Fedora guidelines about that so I'm not sure.
According to https://fedoraproject.org/wiki/Packaging:Tmpfiles.d we're supposed to ship the tmpfiles snippet but also own the directory in the RPM. That way it will be created on first install.
Possibly we should tweak /distribution/beaker/setup to reproduce this in our tests. Currently it avoids the problem because the beaker packages are installed by Anaconda and so then after reboot the tmpfiles snippet is already taking effect. Whereas a real human is more likely to yum install the beaker packages by hand after Anaconda is done (hence hitting this bug).
(In reply to Dan Callaghan from comment #2) https://gerrit.beaker-project.org/5534
This patch makes the beaker-server package on /run/beaker, which lets it start up after a fresh installation: https://gerrit.beaker-project.org/5535 However systemd still complains: Dec 13 09:57:02 belljar.usersys.redhat.com systemd[1]: PID file /var/run/beaker/beakerd.pid not readable (yet?) after start. although the service starts fine and the pid file does exist. So I think that just means the dodgy DaemonContext from python-daemon which we are using is creating the pid file in the wrong order or something. I don't think it's worth fixing though, I would rather just eliminate all double-forking and pid files in favour of systemd notification instead. We can do that once we are no longer targetting RHEL6 as a deployment platform.
(In reply to Dan Callaghan from comment #5) > This patch makes the beaker-server package on /run/beaker I meant, own.
Now that dogfood is reproducing this, I realised it also affects /var/run/beaker-lab-controller which is the directory we are using for the LC daemons (why is it different? I don't know...). So that will need fixing too.
Beaker 24.0 has been released.