When amavisd service init script is called with restart argument, amavis may fail to restart. Reproducible: Always Steps to Reproduce: 1. /etc/init.d/amavisd restart 2. 3. Actual Results: Amavis is shut down Expected Results: Amavis should be stopped and then started backup up (restarted) Essentially what we have here is a race condition. This problem appears to be easiest to reproduce after amavis has been running and processing mail for a period of time, but the bug should be capable of being reproduced within two or three attempts on almost any reasonably fast system. I encountered this problem because I have amavis configured to call SpamAssassin, and I was using the sa-update script in a daily cron job to get new updates. This required me to restart amavis in order to get the new updates into SpamAssassin, and sometimes amavis would not come back up, although logging into the system via ssh and starting the service manually never failed. The whole issue appears to reside within the init script and how it is calling start-stop-deamon. When amavis is stopped, start-stop-daemon sends the master process the kill signal, but never checks to see if the process has actually stopped. However, the init script DOES ask start-stop-daemon to see if amavis is running (via the -name parameter) before actually starting amavis. The net result of this is that if amavis takes a few seconds to spool down (e.g. because it is currently processing mail), the start command will see that amavis is still running and exit without doing anything, when in fact what is occuring is that amavis is still finishing shutting down from the previous stop command. I've attached a simple one-line change to the init-script that appears to resolve the issue (at least on my system). The 120 second timeout is an arbitrary number, chosen in the hopes that it should prove sufficiently long to handle most real-world scenarios. I've seen amavis take upwards of 20 seconds or so to shutdown, depending on the size of the message being processed and how many checks (spam, av) were being done. This may not be the best way to address the problem, however. I just know that it seems to work on my system.
Created attachment 231813 [details, diff] patch to amavisd init script Patch to change service stop behavior
Time taken by amavisd-new to completely shut down (in a worst case scenario) is probably $child_timeout plus some seconds for normal cleanup & shutdown stuff. It defaults to 480 seconds. As far as I can see, a completely correct solution would be to wait $child_timeout plus some seconds.
Playing with configuration a bit reveals that it seems to be a function of the number of threads as well. max_servers defaults to 2. I had mine set to 10 when I was having this problem. Reducing it back to 2 made the problem 'go away'.
Should be fixed with amavisd-new-2.7.0. Please check and reopen if necessary.
