Milter-greylist

> > #0  0x00002abf96fe2346 in poll () from /lib64/libc.so.6
> > #1  0x000000000042c707 in mi_listener ()
> > #2  0x000000000042ba61 in smfi_main ()
> > #3  0x0000000000408a3a in main (argc=<value optimized out>,
> > argv=0x7fffe8df5e18) at milter-greylist.c:2071 (gdb)
> 
> Um we are in libmilter. That one will be hard to debug.
> 

So here we are:

(gdb) thread 3462
[Switching to thread 3462 (Thread 0x2abf9a881940 (LWP 679))]#0  0x00002abf96aeb5f0 in pthread_rwlock_wrlock ()
   from /lib64/libpthread.so.0
(gdb) bt
#0  0x00002abf96aeb5f0 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0
#1  0x000000000040f43c in conf_load_internal (timestamp=<value optimized out>) at conf.c:192
#2  0x00002abf96ae783d in start_thread () from /lib64/libpthread.so.0
#3  0x00002abf96feb26d in clone () from /lib64/libc.so.6
(gdb)

conf.c:192 is ACL_WRLOCK.
I have stopped all the sendmail processes and seemingly the deadlock is still there.
I will have to clean the system now, the production must go on.
It is now code reading phase, is there any thread which can keep that lock
longer than just reading the ACL structure itself in the memory?