Your message dated Mon, 1 May 2006 11:15:42 +0200 with message-id <[EMAIL PROTECTED]> and subject line Bug#360696: Failed to get write lock for /var/spool/exim4/db/retry.lockfile:timedout has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database)
--- Begin Message ---Package: exim4-daemon-heavy Version: 4.60-4 Severity: normal Hello, I'm having a similar problem as the one mentioned in Bug 314356 : 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 == [EMAIL PROTECTED] R=dnslookup T=remote_smtp defer (-44): SMTP error from remote mail server after RCPT TO:<[EMAIL PROTECTED]>: 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). Greetings, Michel -- Package-specific info: Exim version 4.60 #1 built 22-Feb-2006 10:49:24 Copyright (c) University of Cambridge 2005 Berkeley DB: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) Support for: crypteq iconv() IPv6 PAM Perl GnuTLS move_frozen_messages Content_Scanning Old_Demime Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql Authenticators: cram_md5 cyrus_sasl plaintext spa Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp Fixed never_users: 0 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' dc_eximconfig_configtype='internet' dc_other_hostnames='tcnnet.com:tcnnet.dyndns.org' dc_local_interfaces='0.0.0.0.25 : 127.0.0.1.10025' dc_readhost='' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='' dc_mailname_in_oh='true' mailname:tcnnet.dyndns.org -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (650, 'testing'), (600, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages exim4-daemon-heavy depends on: ii exim4-base 4.60-4 support files for all exim MTA (v4 ii libc6 2.3.6-3 GNU C Library: Shared libraries an ii libdb4.2 4.2.52-23.1 Berkeley v4.2 Database Libraries [ ii libgnutls12 1.2.9-2 the GNU TLS library - runtime libr ii libldap2 2.1.30-13 OpenLDAP libraries ii libmysqlclient15 5.0.18-9 mysql database client library ii libpam0g 0.79-3.1 Pluggable Authentication Modules l ii libpcre3 6.4-1.1 Perl 5 Compatible Regular Expressi ii libperl5.8 5.8.8-3 Shared Perl library ii libpq4 8.1.0-3 PostgreSQL C client library ii libsasl2 2.1.19-1.9 Authentication abstraction library exim4-daemon-heavy recommends no packages. -- no debconf information
--- End Message ---
--- Begin Message ---On 2006-04-28 Michel Meyers <[EMAIL PROTECTED]> wrote: > Philip Hazel wrote: > > On Fri, 28 Apr 2006, Michel Meyers wrote: > > > > If that backtrace is to be trusted, Exim's function dbfn_open() has > > called the function __db_pg_free_read_4002() from the libdb library, and > > somewhere in there is where things get stuck. [...] > OK, an update from my side: I never really tried anything on those retry > files but with the above information I went into /var/spool/exim4/db and > found a file called __db.retry, some .lockfiles with 0 bytes size and > some wait-* files (wait-amavis and wait-remote_smtp to be exact). > The wait-* files are 12288 bytes in size, the __db.retry one 4096. Just > for the sake of it, I shut down exim and moved __db.retry out of the > way. [ everthing fine from here on ] Hello, thanks for the followup. I am closing the bug, assuming it was caused by a corrupted file. I have made a small paranoia change to exim4-base: * Whenever changing major Berkeley DB versions we zap the exim hint databases in exim4-base postinst. Change the code to also delete __db.retry, __db.misc, __db.callout and __db.wait* (which afaik are Berkeley DB internal files). If these are somehow broken strange errors occur, e.g. #360696. As we are deleting the whole db, deleting these files seems to be a good idea. (am) 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
--- End Message ---
