Bug 786625 - clamsmtpd won't start because of incorrect "# pidfile:" header
Summary: clamsmtpd won't start because of incorrect "# pidfile:" header
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: clamsmtp
Version: 16
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Nathanael Noblet
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-01 23:22 UTC by Bojan Smojver
Modified: 2012-02-28 15:58 UTC (History)
8 users (show)

Fixed In Version: clamsmtp-1.10-6.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-10 22:00:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Bojan Smojver 2012-02-01 23:22:01 UTC
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.

Comment 1 Jóhann B. Guðmundsson 2012-02-01 23:51:58 UTC
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

Comment 2 Michal Schmidt 2012-02-02 01:14:49 UTC
(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.

Comment 3 Bojan Smojver 2012-02-02 01:46:45 UTC
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.

Comment 4 Fedora Update System 2012-02-02 03:01:41 UTC
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

Comment 5 Fedora Update System 2012-02-02 03:01:50 UTC
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

Comment 6 Fedora Update System 2012-02-02 03:01:59 UTC
clamsmtp-1.10-6.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/clamsmtp-1.10-6.fc16

Comment 7 Fedora Update System 2012-02-02 03:02:08 UTC
clamsmtp-1.10-6.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/clamsmtp-1.10-6.fc15

Comment 8 Michal Schmidt 2012-02-02 13:00:13 UTC
(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?

Comment 9 Fedora Update System 2012-02-02 17:26:01 UTC
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).

Comment 10 Bojan Smojver 2012-02-02 23:20:25 UTC
(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.

Comment 11 Bojan Smojver 2012-02-02 23:24:17 UTC
(In reply to comment #10)
 
> Yes, it eventually timed out. Culprit: mcstrans.

Bug #786182.

Comment 12 Michal Schmidt 2012-02-03 01:05:36 UTC
(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.

Comment 13 Bojan Smojver 2012-02-03 01:09:40 UTC
(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.

Comment 14 Fedora Update System 2012-02-10 22:00:45 UTC
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.

Comment 15 Fedora Update System 2012-02-10 22:02:15 UTC
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.

Comment 16 Fedora Update System 2012-02-20 19:03:04 UTC
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.

Comment 17 Fedora Update System 2012-02-20 19:03:36 UTC
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.

Comment 18 Alan Pevec (Fedora) 2012-02-28 15:51:03 UTC
(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?

Comment 19 Michal Schmidt 2012-02-28 15:58:33 UTC
Perhaps. There is no RFE filed for that, AFAIK.


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