On Sat, 2013-06-08 at 13:27 +0200, Mrten wrote:
Hi,
This morning I discovered what seemed to be a deliberate crash in auth_worker:
Jun 7 23:02:09 localhost dovecot: auth-worker: Error: #007Can't read dir of '/etc/mysql/conf.d/' (Errcode: 2) Jun 7 23:02:09 localhost dovecot: auth-worker: Error: Fatal error in defaults handling. Program aborted Jun 7 23:02:09 localhost dovecot: auth-worker: Error: *** glibc detected *** dovecot/auth worker: waiting for connection: free(): invalid pointer: 0x00007fffa0863160 *** .. /usr/lib/libmysqlclient.so.18(free_defaults+0x4b)[0x7f22d3796e6b] Jun 7 23:02:09 localhost dovecot: auth-worker: Error: /usr/lib/libmysqlclient.so.18(mysql_read_default_options+0x13c)[0x7f22d377d00c] Jun 7 23:02:09 localhost dovecot: auth-worker: Error: /usr/lib/libmysqlclient.so.18(mysql_real_connect+0x8e)[0x7f22d377eb4e]
It crashes in mysql_real_connect() internally, which also starts the whole mysql session. So this is a bug in MySQL library.
This repeated until I killed dovecot (12 hours later), by then 54GB of logs had accumulated. Besides leaving me impressed with the logserver :), I was wondering if this is a known problem.
Shouldn't dovecot recognize that the auth worker is crashing?
Looks like there was a generic problem with how crash during initialization was handled. This should fix all of them: http://hg.dovecot.org/dovecot-2.2/rev/754d244b8249
One more thing, this is (one line from many) from audit.log (I have auditd logging audit records)
type=ANOM_ABEND msg=audit(1370682566.377:3499876): auid=4294967295 uid=108 gid=115 ses=4294967295 pid=23187 comm="auth" reason="memory violation" sig=6
108 is the dovecot user, so it probably is related.
Yeah, that's the same abort() crash.