The problem has been reported [http:\/\/bugs.debian.org\/cgi-bin\/bugreport.cgi?bug=501892 here], but I’m not sure the solution was clearly stated.<\/p>\n
I got this under Ubuntu 9.04, exim4 4.69-9ubuntu1.<\/p>\n
In short, the problem is caused by the following lines in \/etc\/cron.daily\/exim4-base<\/tt>:<\/p>\n
+ find \/var\/spool\/exim4\/db -maxdepth 1 -name *.lockfile \\
\n -or -type f -printf %f\\0
\n + su – –shell \/bin\/bash –command xargs -0r -n 1 \\
\n \/usr\/sbin\/exim_tidydb \/var\/spool\/exim4 > \/dev\/null Debian-exim<\/p>\n
These two lines find files in \/var\/spool\/exim4\/db<\/tt>, where live various databa
\n
\nThe problem has been reported [http:\/\/bugs.debian.org\/cgi-bin\/bugreport.cgi?bug=501892 here], but I’m not sure the solution was clearly stated.<\/p>\n
I got this under Ubuntu 9.04, exim4 4.69-9ubuntu1.<\/p>\n
In short, the problem is caused by the following lines in \/etc\/cron.daily\/exim4-base<\/tt>:<\/p>\n
+ find \/var\/spool\/exim4\/db -maxdepth 1 -name *.lockfile \\
\n -or -type f -printf %f\\0
\n + su – –shell \/bin\/bash –command xargs -0r -n 1 \\
\n \/usr\/sbin\/exim_tidydb \/var\/spool\/exim4 > \/dev\/null Debian-exim<\/p>\n
These two lines find files in \/var\/spool\/exim4\/db<\/tt>, where live various databases used by exim, and perform an exim_tidydb on each file. The files matching *.lockfile are filtered out.<\/p>\n
exim_tidydb thinks there are live databases, and thus try to acquire the lock in file xxx.lock for a file named xxx. This is where the problems occurs.<\/p>\n
In my case, there is another file in the directory, left by some upgrade script:<\/p>\n
# cd \/var\/spool\/exim4\/db\/
\n # ls
\n retry retry.lockfile wait-remote_smtp
\n wait-remote_smtp.lockfile wait-remote_smtp.old<\/p>\n
The faulty file is wait-remote_smtp.old<\/tt>. When operating on it, exim_tidydb tries to acquire non-existent lock filewait-remote_smtp.old.lockfile<\/tt> and fails. <\/p>\n
The solution: just delete that spurious wait-remote_smtp.old<\/tt> or move it elsewhere.<\/p>\n
== How did I come to that ? ==<\/p>\n
By manually stepping through the script lines:<\/p>\n
First I replaced the first line of \/etc\/cron.daily\/exim4-base<\/tt>
\n #!\/bin\/sh
\nby
\n #!\/bin\/sh -x<\/p>\n
This way, the cron output contains every steps done by the script. This is how we spot the 2 faulty lines. Then in order to understand what’s going on, we just play the lines:
\n # cd \/var\/spool\/exim4\/db
\n # find \/var\/spool\/exim4\/db -maxdepth 1 -name *.lockfile -or -type f -print
\n \/var\/spool\/exim4\/db\/retry
\n \/var\/spool\/exim4\/db\/wait-remote_smtp.old
\n \/var\/spool\/exim4\/db\/wait-remote_smtp<\/p>\n
Now a line a bit tricky. The scripts runs as user Debian-exim<\/tt> , so we want to do that too. However this user has no login shell, as a security measure. We thus have to specify a working shell:<\/p>\n
# su – -s \/bin\/bash Debian-exim<\/p>\n
Now we can do our tests:<\/p>\n
# \/usr\/sbin\/exim_tidydb \/var\/spool\/exim4 retry
\n Tidying Exim hints database \/var\/spool\/exim4\/db\/retry
\n Tidying complete<\/p>\n
Doesn’t look bad. Another one:<\/p>\n
# \/usr\/sbin\/exim_tidydb \/var\/spool\/exim4 wait-remote_smtp
\n Tidying Exim hints database \/var\/spool\/exim4\/db\/wait-remote_smtp
\n Tidying complete<\/p>\n
So what ? Let’s try the last one:
\n # \/usr\/sbin\/exim_tidydb \/var\/spool\/exim4 wait-remote_smtp.old
\n Tidying Exim hints database \/var\/spool\/exim4\/db\/wait-remote_smtp.old
\n ** Failed to open database lock
\n file \/var\/spool\/exim4\/db\/wait-remote_smtp.old.lockfile:
\n No such file or directory<\/p>\n
Gotcha.<\/p>\n","protected":false},"excerpt":{"rendered":"
The problem has been reported [http:\/\/bugs.debian.org\/cgi-bin\/bugreport.cgi?bug=501892 here], but I’m not sure the solution was clearly stated. I got this under Ubuntu 9.04, exim4 4.69-9ubuntu1. In […]<\/a><\/p>\n<\/div>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-332","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/tronche.com\/blog\/wp-json\/wp\/v2\/posts\/332","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tronche.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tronche.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tronche.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tronche.com\/blog\/wp-json\/wp\/v2\/comments?post=332"}],"version-history":[{"count":0,"href":"https:\/\/tronche.com\/blog\/wp-json\/wp\/v2\/posts\/332\/revisions"}],"wp:attachment":[{"href":"https:\/\/tronche.com\/blog\/wp-json\/wp\/v2\/media?parent=332"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tronche.com\/blog\/wp-json\/wp\/v2\/categories?post=332"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tronche.com\/blog\/wp-json\/wp\/v2\/tags?post=332"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}