Description of problem: After upgrade to this version of systemd, one of my machines hangs on boot, just after iptables gets started. Also noticed that restart of SysV services like clamdsmtpd and clamsmtp-clamd hangs. Reverting to systemd-36-3 fixes the problem immediately. Version-Release number of selected component (if applicable): 37-11 How reproducible: Always. Steps to Reproduce: 1. Install systemd-37-11. 2. Try to restart above mentioned SysV services or reboot. 3. Hang. Actual results: Hangs. Expected results: Worked fine before. Additional info: On this system, I use traditional network service, not NetworkManager, if it makes any difference.
Try this release http://koji.fedoraproject.org/koji/buildinfo?buildID=296271 If it does not work boot with 'log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg' then save the output of the dmesg command and attach it here. Note there is a default timeout of services of 3 minutes so allow that machine to hang for sometime before giving up and reboot or poweroff. Thanks
(In reply to comment #0) > Also noticed that restart of SysV services like clamdsmtpd and > clamsmtp-clamd hangs. The header in /etc/init.d/clamsmtpd says: # pidfile: /var/run/clamsmtpd/clamsmtpd.pid but the daemon is actually started with "... -p /var/run/clamd.clamsmtp/clamsmtpd.pid" (i.e., a different file name). "# pidfile:" headers must not tell incorrect information. Reassigning to clamsmtp. We can clone the BZ later if it turns out the reporter is seeing more than one bug.
Clamsmtpd aside, having systemd that hangs servers on boot is not a good idea. There was no indication on the boot screen at all that the hang was due to clamsmtpd or clamsmtp-clamd services.
clamsmtp-1.10-6.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/clamsmtp-1.10-6.el5
clamsmtp-1.10-6.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/clamsmtp-1.10-6.el6
clamsmtp-1.10-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/clamsmtp-1.10-6.fc16
clamsmtp-1.10-6.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/clamsmtp-1.10-6.fc15
(In reply to comment #3) > Clamsmtpd aside, having systemd that hangs servers on boot is not a good idea. > There was no indication on the boot screen at all that the hang was due to > clamsmtpd or clamsmtp-clamd services. Did it really hang completely? systemd will timeout the start of a stuck SysV service after 5 minutes. Have you tried waiting at least this long?
Package clamsmtp-1.10-6.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing clamsmtp-1.10-6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-1187/clamsmtp-1.10-6.fc16 then log in and leave karma (feedback).
(In reply to comment #8) > Did it really hang completely? When you reboot a known working system and it gets hung for 3 minutes or so, it is reasonable to think that it's hung. That's why this new requirement for things to be super perfect for systemd scares me. > systemd will timeout the start of a stuck SysV > service after 5 minutes. Have you tried waiting at least this long? Yes, it eventually timed out. Culprit: mcstrans.
(In reply to comment #10) > Yes, it eventually timed out. Culprit: mcstrans. Bug #786182.
(In reply to comment #10) > When you reboot a known working system and it gets hung for 3 minutes or so, it > is reasonable to think that it's hung. That's why this new requirement for > things to be super perfect for systemd scares me. systemd does not wait for the declared PID file to appear just for the fun of it. The wait for the PID file is necessary for daemons that do their double-forking in a racy way. And there's a lot of them, possibly even the majority of all double-forking daemons in existence. Previously their startup under systemd was not deterministic because systemd resorted to a fallback of guessing their main PID. Sometimes the guess was wrong and the daemons were then killed unexpectedly. The new systemd hides the race by waiting for the PID file to appear. This makes it the results deterministic. The original non-determinism was more scary than the requirement to provide true information about one's PID file in a unit file or initscript. It is unfortunate that nobody noticed the mcstrans breakage while the new systemd was in updates-testing. We could have fixed it before moving systemd to updates, like we did for spamassassin.
(In reply to comment #12) > The wait for the PID file is necessary for daemons that do their double-forking > in a racy way. And there's a lot of them, possibly even the majority of all > double-forking daemons in existence. Previously their startup under systemd was > not deterministic because systemd resorted to a fallback of guessing their main > PID. Sometimes the guess was wrong and the daemons were then killed > unexpectedly. > > The new systemd hides the race by waiting for the PID file to appear. This > makes it the results deterministic. > > The original non-determinism was more scary than the requirement to provide > true information about one's PID file in a unit file or initscript. All right, fair enough. Thanks for the info.
clamsmtp-1.10-6.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
clamsmtp-1.10-6.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
clamsmtp-1.10-6.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
clamsmtp-1.10-6.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #12) > The new systemd hides the race by waiting for the PID file to appear. This > makes it the results deterministic. It would be nice if systemd printed something (e.g. every 15s) while waiting on PID file to appear. Is there maybe RFE for that?
Perhaps. There is no RFE filed for that, AFAIK.