This is a discussion on qmail supervise - unable to acquire errors within the alt.comp.mail.qmail forums, part of the Mail Servers and Related category; supervise: fatal: unable to acquire qmail-smtpd/supervise/lock: temporary failure There are lots of posts in qmail groups about ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
supervise: fatal: unable to acquire qmail-smtpd/supervise/lock:
temporary failure There are lots of posts in qmail groups about supervise errors that occur during a qmail stop | start. I couldn't find any posts that were of particular use, so I'm posting this. qmailctl references executables without absolute paths (obviously) so if your path environment variable cannot accomdate qmailctl, 'qmailctl stop' will not shutdown qmail correctly. If you then do 'qmailctl start' you will be starting new qmail processes where old ones have not been shut down. This is what causes the 'unable to acquire' error messages in relation to the various daemons that are run under svcscan. Firstly, to get rid of the annoying screen output, kill svcscan: cat /var/run/svscan.pid # find the PID then use kill to get rid of it Then, find out what qmail processes are still running: ps -axww | grep qmail | grep -v multilog | grep -v supervise (supervise and multilog process aren't a problem) Kill whatever processes you can at this point, so that you're left with whatever zombie process (the ones in square brackets) that have been created because of the ineffectual stop|start. Finally, delete the lock files references in the error messages eg rm -f /var/qmail/supervise/qmail-smtpd/supervise/lock touch them to re-create them eg touch /var/qmail/supervise/qmail-smtpd/supervise/lock (This breaks the lock between the zombie process and the file) and then do a 'qmailctl restart' This works for me. I'm not sure if my logic is entirely correct, but it saves doing a reboot. |