[Dovecot] imap + unmounted home disk
dovecot 0.99 still (RHEL4), I'm sorry to say. The config is for mbox's to live on the user's home disk. If the user tries to make an imap connection when his home disk is unmounted, various permission denied messages are logged, as expected, but then the imap process seems to hang around instead of aborting. The result is that eventually the imap process limit is reached, and even those users whose home disks are correctly mounted, cant get at their mail.
Apologies if this has already been fixed - I cant find anything relevant in the archives.
Cheers, Terry
On 12.3.2007, at 16.40, T. Horsnell wrote:
dovecot 0.99 still (RHEL4), I'm sorry to say. The config is for mbox's to live on the user's home disk. If the user tries to make an imap connection when his home disk is unmounted, various permission denied messages are logged, as expected, but then the imap process seems to hang around instead of aborting. The result is that eventually the imap process limit is reached, and even those users whose home disks are correctly mounted, cant get at their mail.
Check with strace what they are doing? I can't really think of
anything why they would hang.
On Mon, Mar 12, 2007 at 08:55:08PM +0200, Timo Sirainen wrote:
On 12.3.2007, at 16.40, T. Horsnell wrote:
dovecot 0.99 still (RHEL4), I'm sorry to say. The config is for mbox's to live on the user's home disk. If the user tries to make an imap connection when his home disk is unmounted, various permission denied messages are logged, as expected, but then the imap process seems to hang around instead of aborting. The result is that eventually the imap process limit is reached, and even those users whose home disks are correctly mounted, cant get at their mail.
Check with strace what they are doing? I can't really think of
anything why they would hang.
[root@ls1 ~]$ strace -tt -p 17472
Process 17472 attached - interrupt to quit
21:24:52.847645 futex(0x305392f620, FUTEX_WAIT, 2, NULL) = -1 EINTR (Interrupted system call)
21:25:14.933108 --- SIGALRM (Alarm clock) @ 0 (0) ---
21:25:14.933263 alarm(30) = 0
21:25:14.933396 rt_sigreturn(0x1e) = -1 EINTR (Interrupted system call)
21:25:14.933508 futex(0x305392f620, FUTEX_WAIT, 2, NULL) = -1 EINTR (Interrupted system call)
21:25:44.937143 --- SIGALRM (Alarm clock) @ 0 (0) ---
21:25:44.937287 alarm(30) = 0
21:25:44.937403 rt_sigreturn(0x1e) = -1 EINTR (Interrupted system call)
21:25:44.937507 futex(0x305392f620, FUTEX_WAIT, 2, NULL) = -1 EINTR (Interrupted system call)
21:26:14.942092 --- SIGALRM (Alarm clock) @ 0 (0) ---
21:26:14.942244 alarm(30) = 0
21:26:14.942361 rt_sigreturn(0x1e) = -1 EINTR (Interrupted system call)
21:26:14.942469 futex(0x305392f620, FUTEX_WAIT, 2, NULL
Hope this is useful.. Terry.
--
On Mon, 2007-03-12 at 21:26 +0000, T. Horsnell wrote:
[root@ls1 ~]$ strace -tt -p 17472 Process 17472 attached - interrupt to quit 21:24:52.847645 futex(0x305392f620, FUTEX_WAIT, 2, NULL) = -1 EINTR (Interrupted system call) 21:25:14.933108 --- SIGALRM (Alarm clock) @ 0 (0) --- 21:25:14.933263 alarm(30) = 0 21:25:14.933396 rt_sigreturn(0x1e) = -1 EINTR (Interrupted system call)
Hope this is useful..
Hmm. Not really. Dovecot doesn't use threads, so I can't think of why it would be waiting for a futex. What does gdb backtrace show?
gdb attach 17472 bt
Anyway it looks like it's not running in Dovecot's code at all, but somewhere inside libc or something..
On Mon, Mar 12, 2007 at 11:55:13PM +0200, Timo Sirainen wrote:
On Mon, 2007-03-12 at 21:26 +0000, T. Horsnell wrote:
[root@ls1 ~]$ strace -tt -p 17472 Process 17472 attached - interrupt to quit 21:24:52.847645 futex(0x305392f620, FUTEX_WAIT, 2, NULL) = -1 EINTR (Interrupted system call) 21:25:14.933108 --- SIGALRM (Alarm clock) @ 0 (0) --- 21:25:14.933263 alarm(30) = 0 21:25:14.933396 rt_sigreturn(0x1e) = -1 EINTR (Interrupted system call)
Hope this is useful..
Hmm. Not really. Dovecot doesn't use threads, so I can't think of why it would be waiting for a futex. What does gdb backtrace show?
gdb attach 17472 bt
Anyway it looks like it's not running in Dovecot's code at all, but somewhere inside libc or something..
Looks like you're right. Please dont waste any time on this, I thought it might be relevant to the latest stuff. I hope to upgrade soon...
Thanks, Terry.
[root@ls1 ~]$ gdb attach 17472 GNU gdb Red Hat Linux (6.3.0.0-1.63rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...attach: No such file or directory.
Attaching to process 17472 Reading symbols from /usr/libexec/dovecot/imap...(no debugging symbols found)...done. Using host libthread_db library "/lib64/tls/libthread_db.so.1". Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/tls/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2... (no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_files.so.2
0x00000030537d11bb in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6 (gdb) bt #0 0x00000030537d11bb in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6 #1 0x00000000005742c0 in ?? () #2 0x0000000000000001 in ?? () #3 0x000000305376d1c3 in posix_memalign () from /lib64/tls/libc.so.6 #4 0x0000004b00000000 in ?? () #5 0xffffffffffffffff in ?? () #6 0x0000000000000000 in ?? () (gdb) The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/libexec/dovecot/imap, process 17472 [root@ls1 ~]$ file /usr/sbin/dovecot /usr/sbin/dovecot: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped [root@ls1 ~]$
--
participants (2)
-
T. Horsnell
-
Timo Sirainen