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.
