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).
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
Please also check the logs of qmail-* in /var/log/qmail/ and the logs of syslog/metalog.
For the next time, please look at the logs yourself. Have you symlinked /var/qmail/supervise/qmail-{send,smtpd} to /service?
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
Please to use a plain qmail first and get this to work, then build up step for step.
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.
