[Dovecot] status=bounced (Command died with signal 11: "/usr/lib/dovecot/deliver"
Hi list,
I use dovecot 1.1.11 on ubuntu 9.04, when I want to send a message to an email adres on this mailserver I get this error: status=bounced (Command died with signal 11: "/usr/lib/dovecot/deliver".
The folders where the email should be delivered are created so it does not look like a permission problem.
I connect to a mysql database where the email accoutn info is stored, this works.
I use the same setup on an ubuntu 8.04 server with dovecot 1 and I have no problems on that server. What am I overlooking here?
Here is my configuration:
dovecot -n:
base_dir: /var/run/dovecot/ log_path: /var/log/mail.log log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap pop3 imaps pop3s ssl_cert_file: /etc/ssl/certs/dovecot-cert.pem ssl_key_file: /etc/ssl/private/dovecot.pem disable_plaintext_auth: no login_dir: /var/run/dovecot-login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login first_valid_uid: 150 last_valid_uid: 150 mail_privileged_group: mail mail_location: mbox:/var/vmail/%2d/%d/%n mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 auth default: verbose: yes debug: yes debug_passwords: yes passdb: driver: sql args: /etc/dovecot/dovecot-mysql.conf userdb: driver: sql args: /etc/dovecot/dovecot-mysql.conf socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail
postconf -n:
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix/
disable_vrfy_command = no
home_mailbox = Maildir/
inet_interfaces = all
mailbox_size_limit = 0
message_size_limit = 25000000
mydestination = $myhostname, localhost.$mydomain
mydomain = domain.com
myhostname = server.domain.com
mynetworks = 127.0.0.0/24, 10.0.11.248, 10.0.11.249
myorigin = $mydomain
recipient_delimiter = +
setgid_group = postdrop
smtpd_banner = $myhostname
smtpd_client_restrictions = permit_sasl_authenticated permit_mynetworks reject
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks,
reject_unknown_recipient_domain, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
virtual_alias_maps = mysql:$config_directory/mysql_catchall_workaround.cf
mysql:$config_directory/mysql_virtual_alias_maps.cf mysql:
$config_directory/mysql_domain_alias_maps2.cf mysql:
$config_directory/mysql_domain_alias_maps.cf
virtual_gid_maps = static:118
virtual_mailbox_base = /var/vmail
virtual_mailbox_domains = mysql:$config_directory/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = mysql:$config_directory/mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 150
virtual_transport = dovecot
virtual_uid_maps = static:150
On May 22, 2009, at 3:44 AM, Chantal Rosmuller wrote:
I use dovecot 1.1.11 on ubuntu 9.04, when I want to send a message
to an email adres on this mailserver I get this error: status=bounced
(Command died with signal 11: "/usr/lib/dovecot/deliver".
Signal 11 means it crashed. Is this reproducible every time? Having a
gdb backtrace from this crash would be useful. I suppose there's no
core file in the user's home directory? Hmm. Debugging it is probably
going to be annoyingly difficult..
On May 22, 2009, at 3:54 AM, Max Ivanov wrote:
I suppose there's no core file in the user's home directory?
Why? Doesnt them should be autocreated if "ulimit -c " is defined
If it's done in the correct place. That means before Postfix is
started, and that the Postfix init.d script doesn't change it.
and kernel.core_pattern != /dev/null ?
and that deliver has home directory specified and there's no weird
things like SELinux messing things up and probably some other things I
can't remember right now.
At least the very latest Dovecot versions tell if the core file was
written at all. Maybe some day when v2.0 is released people are using
LMTP and that notification gets written too. Or maybe I could try
writing a patch to Postfix and see if they would care about Postfix
logging if core was dumped or not.
On Friday 22 May 2009 09:58:29 Timo Sirainen wrote:
On May 22, 2009, at 3:54 AM, Max Ivanov wrote:
I suppose there's no core file in the user's home directory?
Why? Doesnt them should be autocreated if "ulimit -c " is defined
If it's done in the correct place. That means before Postfix is started, and that the Postfix init.d script doesn't change it.
and kernel.core_pattern != /dev/null ?
and that deliver has home directory specified and there's no weird things like SELinux messing things up and probably some other things I can't remember right now.
At least the very latest Dovecot versions tell if the core file was written at all. Maybe some day when v2.0 is released people are using LMTP and that notification gets written too. Or maybe I could try writing a patch to Postfix and see if they would care about Postfix logging if core was dumped or not.
could this be the problem: /etc/postfix/master.cf
dovecot unix - n n - - pipe flags=DRhu user=vmail:mail argv=/usr/lib/dovecot/deliver -d ${recipient}
maybe dovecot 1.1 needs different flags then 1.0? (Because this works with 1.0)
On 5/22/2009 4:34 AM, Chantal Rosmuller wrote:
could this be the problem: /etc/postfix/master.cf
dovecot unix - n n - - pipe flags=DRhu user=vmail:mail argv=/usr/lib/dovecot/deliver -d ${recipient}
maybe dovecot 1.1 needs different flags then 1.0? (Because this works with 1.0)
First place to check is the wiki... which shows something a little different (but I don't know if it causes your problem):
http://wiki.dovecot.org/LDA/Postfix
--
Best regards,
Charles
On Friday 22 May 2009 12:57:06 Charles Marcus wrote:
On 5/22/2009 4:34 AM, Chantal Rosmuller wrote:
could this be the problem: /etc/postfix/master.cf
dovecot unix - n n - - pipe flags=DRhu user=vmail:mail argv=/usr/lib/dovecot/deliver -d ${recipient}
maybe dovecot 1.1 needs different flags then 1.0? (Because this works with 1.0)
First place to check is the wiki... which shows something a little different (but I don't know if it causes your problem):
No, that's not it :(
On Friday 22 May 2009 09:49:49 Timo Sirainen wrote:
On May 22, 2009, at 3:44 AM, Chantal Rosmuller wrote:
I use dovecot 1.1.11 on ubuntu 9.04, when I want to send a message to an email adres on this mailserver I get this error: status=bounced (Command died with signal 11: "/usr/lib/dovecot/deliver".
Signal 11 means it crashed. Is this reproducible every time? Having a gdb backtrace from this crash would be useful. I suppose there's no core file in the user's home directory? Hmm. Debugging it is probably going to be annoyingly difficult..
It is reproducable, how can I make a gdb backtrace? What is a core file?
ls /path/to/maildir/
drwx------ 2 vmail mail 4096 2009-05-22 09:18 cur -rw------- 1 vmail mail 232 2009-05-22 09:18 dovecot.index.log -rw------- 1 vmail mail 17 2009-05-22 09:18 dovecot-uidlist -rw------- 1 vmail mail 8 2009-05-22 09:18 dovecot-uidvalidity -rw------- 1 vmail mail 0 2009-05-22 09:18 dovecot-uidvalidity.4a1651b8 drwx------ 2 vmail mail 4096 2009-05-22 09:18 new drwx------ 2 vmail mail 4096 2009-05-22 09:18 tmp
On Fri, 2009-05-22 at 10:02 +0200, Chantal Rosmuller wrote:
On Friday 22 May 2009 09:49:49 Timo Sirainen wrote:
On May 22, 2009, at 3:44 AM, Chantal Rosmuller wrote:
I use dovecot 1.1.11 on ubuntu 9.04, when I want to send a message to an email adres on this mailserver I get this error: status=bounced (Command died with signal 11: "/usr/lib/dovecot/deliver".
Signal 11 means it crashed. Is this reproducible every time? Having a gdb backtrace from this crash would be useful. I suppose there's no core file in the user's home directory? Hmm. Debugging it is probably going to be annoyingly difficult..
It is reproducable, how can I make a gdb backtrace? What is a core file?
Try this:
dovecot unix - n n - - pipe flags=DRhu user=vmail:mail argv=/usr/lib/dovecot/gdbhelper /tmp/deliver.sh -d ${recipient}
And /tmp/deliver.sh contains:
#!/bin/sh
sleep 1 exec /usr/lib/dovecot/deliver $*
chmod +x /tmp/deliver.sh and deliver a mail. Hopefully you'll now have /tmp/gdbhelper* file(s)? If so, copy&paste contents.
It is reproducable, how can I make a gdb backtrace? What is a core file?
Try this:
dovecot unix - n n - - pipe flags=DRhu user=vmail:mail argv=/usr/lib/dovecot/gdbhelper /tmp/deliver.sh -d ${recipient}
And /tmp/deliver.sh contains:
#!/bin/sh
sleep 1 exec /usr/lib/dovecot/deliver $*
chmod +x /tmp/deliver.sh and deliver a mail. Hopefully you'll now have /tmp/gdbhelper* file(s)? If so, copy&paste contents.
Ah great I got some debugging info (although not sure what it means)
GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... "/tmp/deliver.sh": not in executable format: File format not recognized Attaching to process 22795 Reading symbols from /bin/dash...(no debugging symbols found)...done. Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libc.so.6 Reading symbols from /lib/ld-linux.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 (no debugging symbols found) 0xb80b3424 in __kernel_vsyscall () (gdb) Signal Stop Print Pass to program Description SIGPIPE No Yes Yes Broken pipe (gdb) Signal Stop Print Pass to program Description SIGALRM No No Yes Alarm clock (gdb) Signal Stop Print Pass to program Description SIG32 No Yes Yes Real-time event 32 (gdb) Continuing. Executing new program: /usr/lib/dovecot/deliver (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found)
Program received signal SIGSEGV, Segmentation fault. 0xb7e0b5bf in unsetenv () from /lib/tls/i686/cmov/libc.so.6 (gdb) #0 0xb7e0b5bf in unsetenv () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #1 0xb7ff80dd in env_remove () from /usr/lib/dovecot/deliver No symbol table info available. #2 0xb7f80ad2 in main () from /usr/lib/dovecot/deliver No symbol table info available. (gdb) The program is running. Exit anyway? (y or n) [answered Y; input not from terminal]
On Tue, 2009-05-26 at 07:49 +0200, Chantal Rosmuller wrote:
Program received signal SIGSEGV, Segmentation fault. 0xb7e0b5bf in unsetenv () from /lib/tls/i686/cmov/libc.so.6 (gdb) #0 0xb7e0b5bf in unsetenv () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #1 0xb7ff80dd in env_remove () from /usr/lib/dovecot/deliver No symbol table info available.
Hmm. Interesting. Is this Ubuntu x86 or x86-64? I can't reproduce this with x86.
Anyway you should be able to work around it by removing boolean settings that are set to "no". What do you get with:
grep '^ *[a-z].*= *no' /etc/dovecot/dovecot.conf
On Tue, 2009-05-26 at 07:49 +0200, Chantal Rosmuller wrote:
Program received signal SIGSEGV, Segmentation fault. 0xb7e0b5bf in unsetenv () from /lib/tls/i686/cmov/libc.so.6 (gdb) #0 0xb7e0b5bf in unsetenv () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #1 0xb7ff80dd in env_remove () from /usr/lib/dovecot/deliver No symbol table info available.
This is a bug in glibc. It also crashes in CentOS 5. Lets see if Ubuntu gets it reported to upstream:
On Tuesday 26 May 2009 08:48:17 Timo Sirainen wrote:
On Tue, 2009-05-26 at 07:49 +0200, Chantal Rosmuller wrote:
Program received signal SIGSEGV, Segmentation fault. 0xb7e0b5bf in unsetenv () from /lib/tls/i686/cmov/libc.so.6 (gdb) #0 0xb7e0b5bf in unsetenv () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #1 0xb7ff80dd in env_remove () from /usr/lib/dovecot/deliver No symbol table info available.
This is a bug in glibc. It also crashes in CentOS 5. Lets see if Ubuntu gets it reported to upstream:
Really? And this is triggered by disable_plaintext_auth = no?
I moved the line but now I get status=deferred (temporary failure)
probably a permission problem, I have been fiddling with the settings to solve the "command died" issue so I probably broke something.
On Tue, 2009-05-26 at 08:59 +0200, Chantal Rosmuller wrote:
On Tuesday 26 May 2009 08:48:17 Timo Sirainen wrote:
On Tue, 2009-05-26 at 07:49 +0200, Chantal Rosmuller wrote:
Program received signal SIGSEGV, Segmentation fault. 0xb7e0b5bf in unsetenv () from /lib/tls/i686/cmov/libc.so.6 (gdb) #0 0xb7e0b5bf in unsetenv () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #1 0xb7ff80dd in env_remove () from /usr/lib/dovecot/deliver No symbol table info available.
This is a bug in glibc. It also crashes in CentOS 5. Lets see if Ubuntu gets it reported to upstream:
Really? And this is triggered by disable_plaintext_auth = no?
Well, it's triggered by the code sequence where environment is first cleared, and when Dovecot sees disable_plaintext_auth=no it makes sure that it's not in environment by calling unsetenv(), which causes glibc to crash. Having another setting in the middle adds a new environment and works around the glibc bug.
I moved the line but now I get status=deferred (temporary failure)
probably a permission problem, I have been fiddling with the settings to solve the "command died" issue so I probably broke something.
Either it's not able to write to log file or it wrote the error to log file.
I moved the line but now I get status=deferred (temporary failure)
probably a permission problem, I have been fiddling with the settings to solve the "command died" issue so I probably broke something.
Either it's not able to write to log file or it wrote the error to log file.
Ah okay sorry I could have figured that out for myself, it's a pretty straight forward permission problem. Thanks!
On Tuesday 26 May 2009 09:03:38 Timo Sirainen wrote:
On Tue, 2009-05-26 at 08:59 +0200, Chantal Rosmuller wrote:
On Tuesday 26 May 2009 08:48:17 Timo Sirainen wrote:
On Tue, 2009-05-26 at 07:49 +0200, Chantal Rosmuller wrote:
Program received signal SIGSEGV, Segmentation fault. 0xb7e0b5bf in unsetenv () from /lib/tls/i686/cmov/libc.so.6 (gdb) #0 0xb7e0b5bf in unsetenv () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #1 0xb7ff80dd in env_remove () from /usr/lib/dovecot/deliver No symbol table info available.
This is a bug in glibc. It also crashes in CentOS 5. Lets see if Ubuntu gets it reported to upstream:
Really? And this is triggered by disable_plaintext_auth = no?
Well, it's triggered by the code sequence where environment is first cleared, and when Dovecot sees disable_plaintext_auth=no it makes sure that it's not in environment by calling unsetenv(), which causes glibc to crash. Having another setting in the middle adds a new environment and works around the glibc bug.
I moved the line but now I get status=deferred (temporary failure)
probably a permission problem, I have been fiddling with the settings to solve the "command died" issue so I probably broke something.
Either it's not able to write to log file or it wrote the error to log file.
I had to change the gid in the dovecot query
old user_query = SELECT '/var/vmail/%2d/%d/%n' as home, 'maildir:/var/vmail/%2d/%d/%n' as mail, 150 AS uid, 118 AS gid, concat('dirsize:storage=',quota) AS quota FROM mailbox WHERE username ='%u' AND active ='1'
new user_query = SELECT '/var/vmail/%2d/%d/%n' as home, 'maildir:/var/vmail/%2d/%d/%n' as mail, 150 AS uid, 8 AS gid, concat('dirsize:storage=',quota) AS quota FROM mailbox WHERE username ='%u' AND active ='1'
It works now, great thanks a lot!
participants (4)
-
Chantal Rosmuller
-
Charles Marcus
-
Max Ivanov
-
Timo Sirainen