A recent update to exim introduced this line to the init.d script: start-stop-daemon --stop --quiet --pidfile /var/run/exim.pid --name exim I now find that exim does not actually restart, or some processes are killed and others are not. The old line: start-stop-daemon --stop --quiet --exec /usr/sbin/exim works perfectly, so I cannot see why it was changed. I have had to edit the init script on a number of servers I run in order to fix the stop() behaviour, so that it can restart for logrotate, etc. Reproducible: Always Steps to Reproduce:
Perhaps I was not clear enough in my original report. On 3 machines I have, another 2 I admin and 1 other I am aware of, exim will fail to restart, requiring administrator intervention (killall then a zap start). When this happens on a high-volume MTA at 3AM because logrotate has tried to restart exim via cron, it is a complete pain. Perhaps it does deserve severity "normal" not "major", but it is still a very broken init script.
being one of the other admins.... ;) I'm paid to run one of these mail server David mentioned. Having an apparently untested init script get in is very bad QA. This bug should be marked as uberCritical IMO. I had to explain to my employer why the mail server died 2 days running, and wasn't fixed till I woke up. Partly my fault for not having suitable service monitoring setup I'll admit, but personally I think this bug is critical.
i'm suffering from the same. Wake up and not having any email in my inbox because exim died. Sure, it'll deliver it some time today, but having a service kill itself isn't really very good at all, and should probably be major/critical not normal...
This was due to a fix for bug #62791, (and was mentioned in the changelog) I fail to understand why you want to restart the whole of exim in the middle of the night via logrotate/cron. For example, the exicyclog script, which comes with exim and I personally tend to use, does not kill any of the running processes as it's not needed. To verify this, set your log_path to somewhere(not just "syslog") and fire up exim in the background, send a mail through it, verify you saw th message in the log file, and without stopping exim, move the log file, send another message, exim will re-create the logfile with the information for the second message.
If we ignore the actual case for restarting exim, can we agree that it is a bug because running /etc/init.d/exim restart does not actually seem to restart exim for a number of people? It is all well and good arguing over semantics but at the end of the day, the init script is broken. "stop" should stop the daemons, it does not. "restart" should restart the daemons, it does not.
um, stop will stop just the listening daemon, which I believe to be the nicer behaviour, otherwise you'll be breaking conversations with your clients/destination hosts, which is generally impolite, the forked processes will die over time any how. There is only one daemon with exim, which forks for each new connection. The startup will work if there are no other instances of exim in memory, (client convesations / queue runners / message delivering processes). stoping with --exec will kill _all_ exim processes, including ones started up on different ports, with different configurations. The fault with it starting appears to be solved by adding the following to the start() section. = start() { ebegin "Starting exim" start-stop-daemon --start --quiet --exec /usr/sbin/exim --pidfile /var/run/exim.pid -- ${EXIM_OPTS:--bd -q15m} eend $? } ==
Mass re-assign, maintainer to whom this bug was assigned seems inactive.
not inactive
I have run into the same problem. Starting seems like it should create a pidfile at /var/run/exim.pid , however it does not. Stop calls this pid file, which doesn't exist, and errors out. I have to kill exim manually, then zap the script. I will probably try one of the fixes. Regardless of how / why people are restarting, this is rather annoying. Is there going to be a fix in portage? Been over eight months now.
(In reply to comment #9) > I have run into the same problem. Starting seems like it should create a pidfile > at /var/run/exim.pid , however it does not. this isn't the same problem, > > Stop calls this pid file, which doesn't exist, and errors out. I have to kill > exim manually, then zap the script. > > I will probably try one of the fixes. > > Regardless of how / why people are restarting, this is rather annoying. Is there > going to be a fix in portage? Been over eight months now. the issue above (exim not stopping), has been fixed, yours is a new bug, please can you make sure you're running the latest exim, with the latest exim init script, and open a new bug with the output of emerge info and also the permissions on /var/run thanks.
no more comments on this bug. fix is in poortage for not stopping the exim process.
