[Dovecot] PAM timed out, kill failed, auth SEGV
My log is full of blocks like this: auth(default): pam(?): PAM child process 13576 timed out, killing it auth(default): PAM: kill(13576) failed: No such process
Often, this is recorded for several pids at once.
Occasionally, there's a single burst when a virtual user logs in,
immediately before pam_authenticate() fails and checkpassword is
executed. When this happens, pam() contains the username and remote IP.
Usually, it starts 2 minutes after a login attempt (successful or
not) and repeats every 10 seconds indefinitely. pam() contains
something else:
~87% ?
~ 9% [garbage],master
~ 4% ?,master
< 1% [empty]
[garbage] varies; it seems to be constant for an instance of auth,
but I haven't verified this.
Eventually, auth segfaults:
Core was generated by `dovecot-auth'.
Program terminated with signal 11, Segmentation fault.
...
#0 0x08087a68 in str_sanitize_append (dest=0x80a8950, src=0x3d9
<Address 0x3d9 out of bounds>, max_len=64) at str-sanitize.c:11
p = 0x3d9 <Address 0x3d9 out of bounds>
#1 0x08057a1d in get_log_str (auth_request=0x80c6a00,
subsystem=0x808f7cd "pam", format=0x808f9ac "PAM child process %s
timed out, killing it", va=0x597f8c5c ":\211\n\b?|\t\b?|\t\b?\214\177Y")
at auth-request.c:1121
ip = 0xa <Address 0xa out of bounds>
str = (string_t *) 0x80a8950
#2 0x08057c62 in auth_request_log_error (auth_request=0x80c6a00,
subsystem=0x808f7cd "pam", format=0x808f9ac "PAM child process %s
timed out, killing it") at auth-request.c:1177
va = 0x597f8c5c ":\211\n\b?|\t\b?|\t\b?\214\177Y"
#3 0x080658ee in pam_child_timeout (context=0x0) at passdb-pam.c:537
request = (struct pam_auth_request *) 0x80c6de8
iter = (struct hash_iterate_context *) 0x80bcdb0
key = (void *) 0xa9e
value = (void *) 0x80c6de8
timeout = 1182548633
#4 0x08079fc5 in io_loop_handle_timeouts (ioloop=0x80b09b0,
update_run_now=true) at ioloop.c:294
t = (struct timeout *) 0x80b4ca8
called_timeouts = (struct timeout *) 0x80b4ca8
tv = {tv_sec = 0, tv_usec = 0}
t_id = 2
#5 0x0807b32e in io_loop_handler_run (ioloop=0x80b09b0) at ioloop-
epoll.c:175
ctx = (struct ioloop_handler_context *) 0x80b09d8
events = (struct epoll_event *) 0x80b0a18
event = (const struct epoll_event *) 0x80b0a18
list = (struct io_list *) 0x80c42d8
io = (struct io *) 0x0
tv = {tv_sec = 1, tv_usec = 180418}
events_count = 12
t_id = 2
msecs = 1181
ret = 0
i = 1
j = 3
call = true
#6 0x0807a0a8 in io_loop_run (ioloop=0x80b09b0) at ioloop.c:329
No locals.
#7 0x0805d7ee in main (argc=1, argv=0x597f8ec4) at main.c:321
foreground = false
My config (Gentoo Linux hardened/x86/2.6): # 1.0.1: /etc/dovecot/dovecot.conf listen: [::1] ssl_listen: [::] ssl_cert_file: /etc/ssl/misfeature.net/crt ssl_key_file: /etc/ssl/misfeature.net/key ssl_cipher_list: HIGH login_dir: /var/run/dovecot/login login_executable: /usr/libexec/dovecot/imap-login login_greeting_capability: yes verbose_proctitle: yes first_valid_uid: 1000 first_valid_gid: 100 mail_location: maildir:~/mail mail_debug: yes maildir_copy_with_hardlinks: yes mail_drop_priv_before_exec: yes imap_client_workarounds: delay-newmail outlook-idle auth default: verbose: yes debug: yes passdb: driver: pam args: * passdb: driver: checkpassword args: /usr/local/bin/checkpassword userdb: driver: passwd userdb: driver: prefetch socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix
I turned on the various logging options while investigating this
problem; the messages appear even without.
-- TA
On Wed, 2007-07-04 at 10:37 -0400, Thomas Arnett wrote:
#2 0x08057c62 in auth_request_log_error (auth_request=0x80c6a00,
subsystem=0x808f7cd "pam", format=0x808f9ac "PAM child process %s
timed out, killing it") at auth-request.c:1177 va = 0x597f8c5c ":\211\n\b?|\t\b?|\t\b?\214\177Y" #3 0x080658ee in pam_child_timeout (context=0x0) at passdb-pam.c:537 request = (struct pam_auth_request *) 0x80c6de8 iter = (struct hash_iterate_context *) 0x80bcdb0 key = (void *) 0xa9e value = (void *) 0x80c6de8 timeout = 1182548633
This should fix the crash: http://hg.dovecot.org/dovecot-1.0/rev/de5d9ffa2a45
It probably doesn't fix the timeout problems though.
participants (2)
-
Thomas Arnett
-
Timo Sirainen