During our boot process we may need to trigger a daemon-reload if the user has provided custom unit files. When doing this we find that, at random, that systemd jobs will be left in the waiting state. This reproduces on systemd 211 and 212. We have also been seeing early boot failures with dracut, again at random, which might be related. Full boot log of a systemd 211 system: https://gist.githubusercontent.com/philips/bd06cab3f0b4db8297ab/raw/d7183136b07b09cc12b5ea702f7e24f39909b1cd/gistfile1.txt
I have also reproduced this with master on a Fedora 20 machine. [root@ip-10-155-147-29 fedora]# cat /etc/systemd/system/daemon-reload.service [Service] ExecStart=/usr/bin/bash -c "while true; do /usr/bin/systemctl daemon-reload; sleep 0.3; done" [Install] WantedBy=local-fs.target [root@ip-10-155-147-29 fedora]# systemctl list-jobs JOB UNIT TYPE STATE 165 getty@tty1.service start waiting 164 getty.target start waiting 167 serial-getty@hvc0.service start waiting 144 systemd-readahead-done.timer start waiting 88 multi-user.target start waiting 147 crond.service start waiting 162 systemd-update-utmp-runlevel.service start waiting 186 sound.target start waiting 8 jobs listed.
I have the suspicion that this is the fix: http://lists.freedesktop.org/archives/systemd-devel/2014-April/018361.html
Lennart- The patch + systemd 212 seems to work. Thanks! Brandon Aside: I tried systemd master + the patch and the machine didn't come back however. I guess master was just broken and I got unlucky.
A fix has been merged: http://cgit.freedesktop.org/systemd/systemd/commit/?id=20a83d7bf4542875f8033b68682a4da4993010e8
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.