Hej,
we have received the following bugreport in Debian BTS by Michel
Meyers on <
http://bugs.debian.org/360696>:
-------------------
[...]
Version: 4.60-4
[...]
I communicate a lot with people defined on an SMTP server that uses
greylisting and whenever that server rejects one of my outgoing e-mails
(meaning that exim has to retry on my side), the respective exim process
gets stuck with 100% CPU usage and the only way to get rid of it is to
kill it with signal 9. While the stuck process is there, the mainlog
keeps mentioning messages like these:
2006-04-04 09:13:33 1FQfgD-0002kv-EZ Failed to get write lock for
/var/spool/exim4/db/retry.lockfile: timed out
2006-04-04 09:13:48 1FQfhL-00035E-Ay Failed to get write lock for
/var/spool/exim4/db/retry.lockfile: timed out
2006-04-04 09:14:48 1FQfhL-00035E-Ay Failed to get write lock for
/var/spool/exim4/db/retry.lockfile: timed out
Other messages are being delivered though but the message that got
rejected by the greylisting server remains stuck until I kill said
process to have it delivered again (at which time the greylisting server
usually lets it through).
Here's an example log entry of a message getting rejected (causing the
process to go to 100% CPU):
2006-04-04 09:31:40 1FQ2wq-0005Kt-8R == removed@??? R=dnslookup
T=remote_smtp defer (-44): SMTP error from remote mail server after RCPT
TO:<removed@???>: host mail.removed.de [xx.xxx.xxx.xx]: 451 GL -
temporary problem. Please try again later.
Could this be a configuration issue on my side or is it a problem with
the code? I use greylistd,
amavis-new and spamassassin on my end and the server hosts multiple domains (lookups done through static alias files for those).
-------------------
I am a little bit at loss on how to debug this, upon asking the
submitter told us that the stuck process is listed as
| 31441 tidying up after delivering 1FT0NS-0008AT-0D
by exiwhat. According to google ther have been similar reports on
exim-users, none of which ended with a definitive solution.
thanks, cu andreas
--
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken. (c) Jasper Ffforde
