Bug 103381 – A really weird qmail startup problem.

• Product: Gentoo Linux
• Status: RESOLVED WORKSFORME

[Description Miroslaw Poray-Zbrozek 2005-08-22 15:16:43 UTC]

I have my private e-mail server at home and I use qmail as an mta. Recently I
have been suffering from power outages every morning due to some construction
work going on in the neighbourhood. I have no UPS so each incident like that
ends up with a system reboot. This is why I have discovered this bug. It turns
out that after a reboot I do not have any process listening on port 25. This is
realy weird because the startup messages say that all the init scripts
inscluding svscan have executed succesfully, also I cannot find anything unusual
in the logs. Doing:
  # ps -eF | grep smtp
reports no qmail-smtp or tpcpserver processes. However when I do:
  # /etc/init.d/svscan restart
everything goes back to normal that is qmail-smtp starts up without any problem
and the server starts listening on port 25 as expected. Unfortunately I do not
know for how long I have had this bug because I usually do system updates
without a reboot unless I change the kernel.

Reproducible: Always
Steps to Reproduce:
1. Reboot the system
2. Try ps -eF | grep smtp OR ps -eF | grep tcpserver OR telnet localhost 25 
3.

Actual Results:  
There is no smtp or tcpserver process running - ps reorts nothing, telnet
Connection Refused

Expected Results:  
ps should have reported something like:
qmaild    7979  7978  0   701   824   0 23:47 tty2     00:00:00
/usr/bin/tcpserver -p -v -R -x /etc/tcprules.d/tcp.qmail-smtp.cdb -c 40 -u 201
-g 200 0.0.0.0 smtp /var/qmail/bin/qmail-smtpd

and telnet should get connected.

First I thought that this had something to do with the courier startup bug
#103014 I reported a couple days ago to be specific I thought that some other
daemon that starts after svscan kills qmail-smtp by accident. This is easy to
check out - I tried to restart one by one those that start after svscan. I
expected one of them to kill qmail-smtp but this did not happen. Also the bug
fix I proposed for bug #103014 does not change anything here. Qmail smtp is
absent after a system reboot with or without that fix. At this poit I have no
clue what this can be. Possibly some process required by qmai-smtp or tcpserver
starts up too slowly and is not ready when needed by qmail? Another guess was
that this had something to do with an undefined state of the hardware clock - I
use ntp-client for synchronization and it does start after svscan, but when I
checked the BIOS directly the time was correct (it is set up to UTC and I do
have an option to adjust it at reboot time in my /etc/conf.d/clock file set to yes).

[Comment 1 Miroslaw Poray-Zbrozek 2005-08-22 15:27:08 UTC]

I forgot to give the details about my qmail version. I have the following apps
related to qmail installed:
mail-mta/qmail-1.03-r15 
mail-filter/spamassassin-3.0.4
app-antivirus/clamav-0.86.1
mail-filter/qmail-scanner-1.25-r1
sys-apps/ucspi-tcp-0.88-r10

[Comment 2 Michael Hanselmann (hansmi) (RETIRED) 2005-08-25 14:31:52 UTC]

Please also check the logs of qmail-* in /var/log/qmail/ and the logs of
syslog/metalog.

[Comment 3 Michael Hanselmann (hansmi) (RETIRED) 2005-08-27 07:10:06 UTC]

For the next time, please look at the logs yourself. Have you symlinked
/var/qmail/supervise/qmail-{send,smtpd} to /service?

[Comment 4 Miroslaw Poray-Zbrozek 2005-08-27 12:20:22 UTC]

I apologize for sending you my logs, I did not do that with an intention to take
your precious time or to do my job for me - as mentioned before I read them but
I could not find anything wrong there. I simply misuderstood your post and I
thought you wanted them. And of course I do have the symlinks you ask about.
Qmail whould not start at all without them. This is what I have in /service:

drwxr-xr-x   2 root root 136 Mar 24 21:24 .
drwxr-xr-x  22 root root 568 Aug 15 17:24 ..
-rw-r--r--   1 root root   0 Mar 24 12:04 .keep
lrwxrwxrwx   1 root root  31 Mar 24 21:23 qmail-send ->
/var/qmail/supervise/qmail-send
lrwxrwxrwx   1 root root  32 Mar 24 21:24 qmail-smtpd ->
/var/qmail/supervise/qmail-smtpd

[Comment 5 Michael Hanselmann (hansmi) (RETIRED) 2005-09-05 13:20:26 UTC]

Please to use a plain qmail first and get this to work, then build up step for step.

[Comment 6 Miroslaw Poray-Zbrozek 2005-09-08 15:44:19 UTC]

I did a clean reinstallation of qmail that is i unmerged qmail and removed all
the remaining /var/lib/qmai files ant then I remerged the most recent version
(1.03-r16) and reconfigured it. I also did emerge -uD world to make sure that
everything else is up to date.

Unfortunately the behavior is unchanged that is after a reboot there are no
qmail processes present but after restarting svscan everythig works OK.

Then I tried a couple experiments that may shed some light on the problem. One
thing that I tried is adding --background option to the start-stop-daemon line
in /etc/init.d/svscan. With this option all the qmail processes are present
after a reboot however this is not a good permanent solution because it is
impossible to control them with svscan afterwards that is /etc/init.d/svscan
stop or restart is unable to communicate with those processes so the only way to
get rid of them is to kill them manually.

This behavior suggests that the processes controlled by the unmodified svscan
script do not detach and go into the background properly and that is the reason
why they get killed. This may mean that the problem is burried much deeper in
the base layout or system libraries. I think about rebuilding this system from
scratch when I have time to do that.