Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[qmail] multilog: fatal: unable to lock directory

547 views
Skip to first unread message

Felix Stiehler

unread,
Feb 14, 2011, 3:16:23 PM2/14/11
to
Hi,

I had a running netqmail-1.0.6 installation for some time and was now
adding SMTP AUTH functionality. I did this with the qmail patch
qmail-authentication-0.7.1 from

http://www.fehcom.de/qmail/smtpauth.html

For the authentication i use cmd5checkpw. Everything runs somewhat
smoothly but i have this errors reported from readproctitle:

root 30555 0.0 0.0 3636 340 ? S Feb04 0:00
readproctitle service errors: ...ultilog: fatal: unable to lock
directory /var/log/qmail/smtpd: temporary failure?multilog: fatal:
unable to lock directory /var/log/qmail: temporary failure?multilog:
fatal: unable to lock directory /var/log/qmail/smtpd: temporary
failure?multilog: fatal: unable to lock directory /var/log/qmail:
temporary failure?multilog: fatal: unable to lock directory
/var/log/qmail/smtpd: temporary failure?

The logs seem to work but it is somewhat unpleasent to have this. I
restartet the multilog multiple times as well as the supervise deamons
and the errors remain.

Any ideas how to fix this would be nice.


Felix Stiehler

P.S.: it really feels like there is native SMTP AUTH support needed in qmail


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

Andy Bradford

unread,
Feb 14, 2011, 8:23:17 PM2/14/11
to
Thus said Felix Stiehler on Mon, 14 Feb 2011 21:16:23 +0100:

> The logs seem to work but it is somewhat unpleasent to have this. I
> restartet the multilog multiple times as well as the supervise deamons
> and the errors remain.

It's possible that this is stale information. Does svstat show that all
your processes are running:

svstat /service/* /service/*/log

If so, either reboot, or create a service that clears out readproctitle
information:

(untested mostly but appears correct):

mkdir /var/supervise/cleanproctitle
cat <<EOF>/var/supervise/cleanproctitle/run
#!/bin/sh
echo -n '.'
exec sleep 60
EOF
chmod 755 /var/supervise/cleanproctitle/run
ln -s /var/supervise/cleanproctitle /service

Andy

Felix Stiehler

unread,
Feb 16, 2011, 4:16:01 PM2/16/11
to
On 02/15/2011 02:23 AM, Andy Bradford wrote:
> Thus said Felix Stiehler on Mon, 14 Feb 2011 21:16:23 +0100:
>
>> The logs seem to work but it is somewhat unpleasent to have this. I
>> restartet the multilog multiple times as well as the supervise deamons
>> and the errors remain.
> It's possible that this is stale information. Does svstat show that all
> your processes are running:
>
> svstat /service/* /service/*/log
>
> If so, either reboot, or create a service that clears out readproctitle
> information:
>
> (untested mostly but appears correct):
>
> mkdir /var/supervise/cleanproctitle
> cat<<EOF>/var/supervise/cleanproctitle/run
> #!/bin/sh
> echo -n '.'
> exec sleep 60
> EOF
> chmod 755 /var/supervise/cleanproctitle/run
> ln -s /var/supervise/cleanproctitle /service
>
> Andy
>
The reboot fixed it, thanks a lot!

Felix

0 new messages