Exit status code 134; what is it, in the context of Dovecot Antispam plug-in?
Hello!
I just migrated from Ubuntu 12.04 LTS to 14.04 LTS and thereby from Dovecot 2.0.19 to 2.2.9.
I've been using dovecot-antispam plugin with great success for the past year with 2.0.19, but after this migration, I've been seeing the exit status code 134 in the syslog when attempting to debug the Dovecot Antispam plugin not working after the migration.
I have some debugging output in my pipe script; the output looks something like this:
Copying message contents to temporary file for debugging purposes; file is: /tmp/sendmail-msg-7662.txt Checking if the command-line input argument string (--spam) contains the string "ham" or "spam" Mode is "SPAM" Calling (as user vmail) '/usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.SPAM" -p "/tmp/sendmail-msg-7662.txt"' Exit status was 134
Yet, I'm able to copy the above command and execute it manually, via the command-line, and it works (and by "works", I mean to say that the behavior is correct and exactly as expected; I receive the "Spam" email at the designated mailbox). Here's how I'm calling it when it works perfectly well (as "root"):
# su -c '/usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.HAM" -p "/tmp/sendmail-msg-7460.txt"' vmail
Any idea what status 134 might be or how to work around it? It looks to be some kind of "temporary failure exception", but that is less than informative in this context.
"doveconf -n" output is appended.
Thanks for any help!
-Ben
# 2.2.9: /etc/dovecot/dovecot.conf # OS: Linux 3.13.0-32-generic x86_64 Ubuntu 14.04.1 LTS auth_mechanisms = plain login disable_plaintext_auth = no listen = *,[::] log_timestamp = "%Y-%m-%d %H:%M:%S " mail_privileged_group = vmail managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave passdb { args = /etc/dovecot/dovecot-sql.conf driver = sql } plugin { antispam_backend = pipe antispam_debug_target = syslog antispam_pipe_program = /bin/bash antispam_pipe_program_args = /usr/local/bin/sa-learn-pipe.sh antispam_pipe_program_notspam_arg = --ham antispam_pipe_program_spam_arg = --spam antispam_pipe_tmpdir = /tmp antispam_spam_pattern_ignorecase = SPAM;JUNK antispam_trash_pattern_ignorecase = trash;Deleted * antispam_verbose_debug = 1 quota = dict:user::file:/var/vmail/%d/%n/.quotausage quota_rule2 = Trash:storage=+100M quota_rule3 = Junk:ignore quota_rule4 = INBOX:storage=+100M quota_warning = storage=100%% quota-reached 100 %u %d quota_warning2 = storage=95%% quota-warning 95 %u %d quota_warning3 = storage=80%% quota-warning 80 %u %d quota_warning4 = -storage=100%% quota-below below %u %d sieve = /var/vmail/%d/%n/.sieve } postmaster_address = postmaster@example.com protocols = imap pop3 sieve service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } unix_listener auth-userdb { group = vmail mode = 0600 user = vmail } user = root } service config { unix_listener config { group = vmail mode = 0600 user = vmail } } service imap-login { client_limit = 1000 process_limit = 500 } service quota-below { executable = script /usr/local/bin/quota-below.sh unix_listener quota-below { group = vmail mode = 0666 user = vmail } user = vmail } service quota-reached { executable = script /usr/local/bin/quota-reached.sh unix_listener quota-reached { group = vmail mode = 0666 user = vmail } user = vmail } service quota-warning { executable = script /usr/local/bin/quota-warning.sh unix_listener quota-warning { group = vmail mode = 0666 user = vmail } user = vmail } ssl_cert =
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 28 Jul 2014, Ben Johnson wrote:
I have some debugging output in my pipe script; the output looks
How does your script looks like?
Copying message contents to temporary file for debugging purposes; file is: /tmp/sendmail-msg-7662.txt Checking if the command-line input argument string (--spam) contains the string "ham" or "spam" Mode is "SPAM" Calling (as user vmail) '/usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.SPAM" -p "/tmp/sendmail-msg-7662.txt"' Exit status was 134
Check out your local /usr/include/sysexits.h, if the exit code is defined there. It's not in mine.
Yet, I'm able to copy the above command and execute it manually, via the command-line, and it works (and by "works", I mean to say that the behavior is correct and exactly as expected; I receive the "Spam" email at the designated mailbox). Here's how I'm calling it when it works perfectly well (as "root"):
# su -c '/usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.HAM" -p "/tmp/sendmail-msg-7460.txt"' vmail
Any idea what status 134 might be or how to work around it? It looks to be some kind of "temporary failure exception", but that is less than informative in this context.
# 2.2.9: /etc/dovecot/dovecot.conf # OS: Linux 3.13.0-32-generic x86_64 Ubuntu 14.04.1 LTS plugin { antispam_backend = pipe antispam_debug_target = syslog antispam_pipe_program = /bin/bash antispam_pipe_program_args = /usr/local/bin/sa-learn-pipe.sh antispam_pipe_program_notspam_arg = --ham antispam_pipe_program_spam_arg = --spam antispam_pipe_tmpdir = /tmp antispam_spam_pattern_ignorecase = SPAM;JUNK antispam_trash_pattern_ignorecase = trash;Deleted * antispam_verbose_debug = 1 }
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBU9dJrnz1H7kL/d9rAQIskggAt2Otvh4sHZPrmYNm2aSiUwJqarmZmiLV KrXuMwuvDs33Wd60Bihqjykw96fwz3v+jQuqx+t/V+uN/jRffFpp98aUA4rR9rZ6 AJ3HJfPTyf11Pi9cCG8EhqmY9amPRFrp1Ox+NCg4Jt2liUPzmdtPe6+OUR+QlUdR Dr2Q6nyH+0sA948mnihJRVERf/oY+7/1s/UTLtCyyGGm4nXy9yoFWVeGxIybXF8G HMH0I1CYCvKVtmh3o/6IaqJD7IIvJGcUPcEiSNtoKAUC5hu1IhwwkbZnD9IEiigG HPDL0JIBZBleU8/6SC+e7eP7SF6deu4db1E/I45JVNOZLsZjzgtIVA== =5sDi -----END PGP SIGNATURE-----
On 7/29/2014 3:13 AM, Steffen Kaiser wrote:
On Mon, 28 Jul 2014, Ben Johnson wrote:
I have some debugging output in my pipe script; the output looks
How does your script looks like?
Copying message contents to temporary file for debugging purposes; file is: /tmp/sendmail-msg-7662.txt Checking if the command-line input argument string (--spam) contains the string "ham" or "spam" Mode is "SPAM" Calling (as user vmail) '/usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.SPAM" -p "/tmp/sendmail-msg-7662.txt"' Exit status was 134
Check out your local /usr/include/sysexits.h, if the exit code is defined there. It's not in mine.
Exit code 134 is not defined in /usr/include/sysexits.h on my system.
Yet, I'm able to copy the above command and execute it manually, via the command-line, and it works (and by "works", I mean to say that the behavior is correct and exactly as expected; I receive the "Spam" email at the designated mailbox). Here's how I'm calling it when it works perfectly well (as "root"):
# su -c '/usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.HAM" -p "/tmp/sendmail-msg-7460.txt"' vmail
Any idea what status 134 might be or how to work around it? It looks to be some kind of "temporary failure exception", but that is less than informative in this context.
# 2.2.9: /etc/dovecot/dovecot.conf # OS: Linux 3.13.0-32-generic x86_64 Ubuntu 14.04.1 LTS plugin { antispam_backend = pipe antispam_debug_target = syslog antispam_pipe_program = /bin/bash antispam_pipe_program_args = /usr/local/bin/sa-learn-pipe.sh antispam_pipe_program_notspam_arg = --ham antispam_pipe_program_spam_arg = --spam antispam_pipe_tmpdir = /tmp antispam_spam_pattern_ignorecase = SPAM;JUNK antispam_trash_pattern_ignorecase = trash;Deleted * antispam_verbose_debug = 1 }
-- Steffen Kaiser
Is it possible that this is some kind of apparmor restriction? I ask because apparmor is indeed installed on this machine.
If you examine the script source (cited above), you will see that I've had to use "the hammer that is strace" to debug issues with Dovecot + Antispam before... maybe it's worth trying in this case.
Happy to hear any further suggestions.
Thanks again,
-Ben
On 7/29/2014 11:20 AM, Ben Johnson wrote:
On 7/29/2014 3:13 AM, Steffen Kaiser wrote:
On Mon, 28 Jul 2014, Ben Johnson wrote:
I have some debugging output in my pipe script; the output looks
How does your script looks like?
Copying message contents to temporary file for debugging purposes; file is: /tmp/sendmail-msg-7662.txt Checking if the command-line input argument string (--spam) contains the string "ham" or "spam" Mode is "SPAM" Calling (as user vmail) '/usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.SPAM" -p "/tmp/sendmail-msg-7662.txt"' Exit status was 134
Check out your local /usr/include/sysexits.h, if the exit code is defined there. It's not in mine.
Exit code 134 is not defined in /usr/include/sysexits.h on my system.
Yet, I'm able to copy the above command and execute it manually, via the command-line, and it works (and by "works", I mean to say that the behavior is correct and exactly as expected; I receive the "Spam" email at the designated mailbox). Here's how I'm calling it when it works perfectly well (as "root"):
# su -c '/usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.HAM" -p "/tmp/sendmail-msg-7460.txt"' vmail
Any idea what status 134 might be or how to work around it? It looks to be some kind of "temporary failure exception", but that is less than informative in this context.
# 2.2.9: /etc/dovecot/dovecot.conf # OS: Linux 3.13.0-32-generic x86_64 Ubuntu 14.04.1 LTS plugin { antispam_backend = pipe antispam_debug_target = syslog antispam_pipe_program = /bin/bash antispam_pipe_program_args = /usr/local/bin/sa-learn-pipe.sh antispam_pipe_program_notspam_arg = --ham antispam_pipe_program_spam_arg = --spam antispam_pipe_tmpdir = /tmp antispam_spam_pattern_ignorecase = SPAM;JUNK antispam_trash_pattern_ignorecase = trash;Deleted * antispam_verbose_debug = 1 }
-- Steffen Kaiser
Is it possible that this is some kind of apparmor restriction? I ask because apparmor is indeed installed on this machine.
If you examine the script source (cited above), you will see that I've had to use "the hammer that is strace" to debug issues with Dovecot + Antispam before... maybe it's worth trying in this case.
Happy to hear any further suggestions.
Thanks again,
-Ben
Still struggling with this. strace doesn't reveal anything useful, either.
In short, dovecot deliver is returning with exit code 134 when I try to execute the following command in the context of my dovecot-antispam pipe script:
/usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.HAM" -p "/tmp/sendmail-msg-7460.txt"' vmail
Yet, if I execute the same exact command after su-ing to the vmail user, it works:
# su vmail $ whoami vmail $ /usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.HAM" -p "/tmp/sendmail-msg-7460.txt"
I have ensured that the pipe script is, in fact, being executed as the vmail user, by inserting the following into my debug output:
CURRENT_USER=$(whoami) echo "$CURRENT_USER"
This outputs "vmail".
I have this working with exactly the same setup (near as I can tell) on a machine with Dovevot 2.0.19 (via Ubuntu 12.04 LTS). This problem machine is running 2.2.9 (via Ubuntu 14.04 LTS). My "doveconf -n" output is at the bottom of my original post.
I would love to figure this out; it will be the capstone on an otherwise perfect build. :)
Thanks for any ideas!
-Ben
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 7 Aug 2014, Ben Johnson wrote:
On 7/29/2014 11:20 AM, Ben Johnson wrote:
On 7/29/2014 3:13 AM, Steffen Kaiser wrote:
On Mon, 28 Jul 2014, Ben Johnson wrote:
I have some debugging output in my pipe script; the output looks
How does your script looks like?
Copying message contents to temporary file for debugging purposes; file is: /tmp/sendmail-msg-7662.txt Checking if the command-line input argument string (--spam) contains the string "ham" or "spam" Mode is "SPAM" Calling (as user vmail) '/usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.SPAM" -p "/tmp/sendmail-msg-7662.txt"' Exit status was 134
Check out your local /usr/include/sysexits.h, if the exit code is defined there. It's not in mine.
Exit code 134 is not defined in /usr/include/sysexits.h on my system.
Yet, I'm able to copy the above command and execute it manually, via the command-line, and it works (and by "works", I mean to say that the behavior is correct and exactly as expected; I receive the "Spam" email at the designated mailbox). Here's how I'm calling it when it works perfectly well (as "root"):
# su -c '/usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.HAM" -p "/tmp/sendmail-msg-7460.txt"' vmail
Any idea what status 134 might be or how to work around it? It looks to be some kind of "temporary failure exception", but that is less than informative in this context.
# 2.2.9: /etc/dovecot/dovecot.conf # OS: Linux 3.13.0-32-generic x86_64 Ubuntu 14.04.1 LTS plugin { antispam_backend = pipe antispam_debug_target = syslog antispam_pipe_program = /bin/bash antispam_pipe_program_args = /usr/local/bin/sa-learn-pipe.sh antispam_pipe_program_notspam_arg = --ham antispam_pipe_program_spam_arg = --spam antispam_pipe_tmpdir = /tmp antispam_spam_pattern_ignorecase = SPAM;JUNK antispam_trash_pattern_ignorecase = trash;Deleted * antispam_verbose_debug = 1 }
-- Steffen Kaiser
Is it possible that this is some kind of apparmor restriction? I ask because apparmor is indeed installed on this machine.
Well, of course apparmor can interject with any operation. You ought to see that in the apparmor logs. I do not have no experience with it though.
If you examine the script source (cited above), you will see that I've had to use "the hammer that is strace" to debug issues with Dovecot + Antispam before... maybe it's worth trying in this case.
Still struggling with this. strace doesn't reveal anything useful, either.
In short, dovecot deliver is returning with exit code 134 when I try to execute the following command in the context of my dovecot-antispam pipe script:
/usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.HAM" -p "/tmp/sendmail-msg-7460.txt"' vmail
Yet, if I execute the same exact command after su-ing to the vmail user, it works:
# su vmail $ whoami vmail $ /usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.HAM" -p "/tmp/sendmail-msg-7460.txt"
I have ensured that the pipe script is, in fact, being executed as the vmail user, by inserting the following into my debug output:
CURRENT_USER=$(whoami) echo "$CURRENT_USER"
This outputs "vmail".
I have this working with exactly the same setup (near as I can tell) on a machine with Dovevot 2.0.19 (via Ubuntu 12.04 LTS). This problem machine is running 2.2.9 (via Ubuntu 14.04 LTS). My "doveconf -n" output is at the bottom of my original post.
I would love to figure this out; it will be the capstone on an otherwise perfect build. :)
Thanks for any ideas!
one idea: http://www.tldp.org/LDP/abs/html/exitcodes.html
exit code 134 would be in bash's meaning (if this website is correct all) some program died off signal 6. This would be Abort in Linux.
prepend your script with
exec >> /tmp/trace 2>&1 set -vx
that will dump anything visible into /tmp/trace
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBU+OX4Xz1H7kL/d9rAQKMywgAmXzynP+lVcPhKfrQ+O3gih98+6C50lD5 g1jmKuGuiiPxBruD1Z4M9tCajN0t4bBBXQKUdvyNedms+iIi94sTEmC14DUq//+g M/Fu/0FL2RZxS3NaaYcR5vz3jrHcGDBKewffbWauRHMF0PIy4IOCTeTwSvjAFleb dBI51KhHWDqYw7T4ZGAAgZlp2ympG1PA2NU0YaSy87oa2WGoIii7F8AgvSaze/0j kwZZKfg35C5/zrWyRixSompjUJzUAaKc4TmWxggjejGv+yiJHxiTFgpCwBsci2XA KHfSOzAyezfvXTS1ZdC+yXYuqUAERZj6ArtHKmsu/aSCDg9T9w4ZVw== =6cGs -----END PGP SIGNATURE-----
On 8/7/2014 11:14 AM, Steffen Kaiser wrote:
one idea: http://www.tldp.org/LDP/abs/html/exitcodes.html
exit code 134 would be in bash's meaning (if this website is correct all) some program died off signal 6. This would be Abort in Linux.
prepend your script with
exec >> /tmp/trace 2>&1 set -vx
that will dump anything visible into /tmp/trace
- -- Steffen Kaiser
Thank you for your continued assistance, Steffen.
You seem to be exactly correct with the Abort signal.
I prepended the values you suggested to the pipe script and here's the relevant output:
- /usr/lib/dovecot/deliver -d sa-training@example.com -m Training.SPAM ^A^H5584 prefix=lda: ^A^F5584 io_add(0x1) called twice fd=7, callback=0x7f23489fb6f0 -> 0x7f23489aa530 ^A^D5584 Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0x5e271) [0x7f23489e9271] -> /usr/lib/dovecot/libdovecot.so.0(+0x5e34e) [0x7f23489e934e] -> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7f23489a4a9e] -> /usr/lib/dovecot/libdovecot.so.0(ioloop_iolist_add+0x83) [0x7f23489f9533] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handle_add+0x3b) [0x7f23489f9cbb] -> /usr/lib/dovecot/libdovecot.so.0(io_add+0x9b) [0x7f23489f89fb] -> /usr/lib/dovecot/libdovecot.so.0(master_service_io_listeners_add+0x69) [0x7f23489a9e49] -> /usr/lib/dovecot/libdovecot.so.0(master_service_init_finish+0xb0) [0x7f23489a9f90] -> /usr/lib/dovecot/deliver(main+0x1cb) [0x7f234939269b] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f23485e6ec5] -> /usr/lib/dovecot/deliver(+0x31de) [0x7f23493931de] /usr/local/bin/sa-learn-pipe.sh: line 52: 5584 Aborted (core dumped) /usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.$mode"
- echo 'Exit status was 134'
Does this tell us anything more?
I don't see any indication that apparmor is at play, as there is no profile that should apply in this context (and there is nothing in the relevant log file):
# service apparmor status apparmor module is loaded. 8 profiles are loaded. 8 profiles are in enforce mode. /sbin/dhclient /usr/bin/freshclam /usr/lib/NetworkManager/nm-dhcp-client.action /usr/lib/connman/scripts/dhclient-script /usr/sbin/clamd /usr/sbin/mysqld /usr/sbin/ntpd /usr/sbin/tcpdump 0 profiles are in complain mode. 4 processes have profiles defined. 4 processes are in enforce mode. /usr/bin/freshclam (2015) /usr/sbin/clamd (1897) /usr/sbin/mysqld (1239) /usr/sbin/ntpd (2472) 0 processes are in complain mode. 0 processes are unconfined but have a profile defined.
I'll try to reproduce this on an identically-configured server. I wonder if it would be worth changing the version of Dovecot. But I hate to play whack-a-mole if a more systematic approach is to be had.
Thanks again,
-Ben
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 7 Aug 2014, Ben Johnson wrote:
On 8/7/2014 11:14 AM, Steffen Kaiser wrote:
one idea: http://www.tldp.org/LDP/abs/html/exitcodes.html
exit code 134 would be in bash's meaning (if this website is correct all) some program died off signal 6. This would be Abort in Linux.
prepend your script with
exec >> /tmp/trace 2>&1 set -vx
that will dump anything visible into /tmp/trace
- -- Steffen Kaiser
Thank you for your continued assistance, Steffen.
You seem to be exactly correct with the Abort signal.
I prepended the values you suggested to the pipe script and here's the relevant output:
- /usr/lib/dovecot/deliver -d sa-training@example.com -m Training.SPAM ^A^H5584 prefix=lda: ^A^F5584 io_add(0x1) called twice fd=7, callback=0x7f23489fb6f0 -> 0x7f23489aa530
Unfortunately the only spot found is: http://dovecot.org/pipermail/dovecot/2012-May/135636.html
Is it the same fd=# always? Is it already open in your script? You could check with lsof -p $$
However, you should check if Dovecot v2.2.13 already fixes the problem.
^A^D5584 Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0x5e271) [0x7f23489e9271] -> /usr/lib/dovecot/libdovecot.so.0(+0x5e34e) [0x7f23489e934e] -> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7f23489a4a9e] -> /usr/lib/dovecot/libdovecot.so.0(ioloop_iolist_add+0x83) [0x7f23489f9533] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handle_add+0x3b) [0x7f23489f9cbb] -> /usr/lib/dovecot/libdovecot.so.0(io_add+0x9b) [0x7f23489f89fb] -> /usr/lib/dovecot/libdovecot.so.0(master_service_io_listeners_add+0x69) [0x7f23489a9e49] -> /usr/lib/dovecot/libdovecot.so.0(master_service_init_finish+0xb0) [0x7f23489a9f90] -> /usr/lib/dovecot/deliver(main+0x1cb) [0x7f234939269b] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f23485e6ec5] -> /usr/lib/dovecot/deliver(+0x31de) [0x7f23493931de] /usr/local/bin/sa-learn-pipe.sh: line 52: 5584 Aborted (core dumped) /usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.$mode"
- echo 'Exit status was 134'
Does this tell us anything more?
I don't see any indication that apparmor is at play, as there is no profile that should apply in this context (and there is nothing in the relevant log file):
# service apparmor status apparmor module is loaded. 8 profiles are loaded. 8 profiles are in enforce mode. /sbin/dhclient /usr/bin/freshclam /usr/lib/NetworkManager/nm-dhcp-client.action /usr/lib/connman/scripts/dhclient-script /usr/sbin/clamd /usr/sbin/mysqld /usr/sbin/ntpd /usr/sbin/tcpdump 0 profiles are in complain mode. 4 processes have profiles defined. 4 processes are in enforce mode. /usr/bin/freshclam (2015) /usr/sbin/clamd (1897) /usr/sbin/mysqld (1239) /usr/sbin/ntpd (2472) 0 processes are in complain mode. 0 processes are unconfined but have a profile defined.
I'll try to reproduce this on an identically-configured server. I wonder if it would be worth changing the version of Dovecot. But I hate to play whack-a-mole if a more systematic approach is to be had.
Thanks again,
-Ben
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBU+SMkXz1H7kL/d9rAQL7owf/UoNtkoN02JU/1ODYJCaccrpZFTaW1L98 hUPs40eAkh7XsCCe8ymBlG8PzTushkDlqW1EGY2JP3qr5wFV9ACG9ga1Z2oik7CE R3ELjcB6z4D7j2gIHbSGeF+rAIwP2I8K4tVwd4bfVDm2nv+8fAC2OFo4osark1Z9 +3szhhwYIdlon3droAKkUarppXLX9AiYRHHrIpd3ITI55r1x3D6Ni8ClTmyIqKk2 fuKvrFCzU+OIkBegguLfHjhtU6iG4t6RWgb6X77YfnfNy4jHcbeHc9j0dKL4/bP8 Cy5ro1twUcqtC7qQY2kdI3Ka59+dGFhoewFczEsZ8cVOb+ivpv2MiQ== =VORN -----END PGP SIGNATURE-----
On 8/8/2014 4:38 AM, Steffen Kaiser wrote:
On Thu, 7 Aug 2014, Ben Johnson wrote:
On 8/7/2014 11:14 AM, Steffen Kaiser wrote:
one idea: http://www.tldp.org/LDP/abs/html/exitcodes.html
exit code 134 would be in bash's meaning (if this website is correct all) some program died off signal 6. This would be Abort in Linux.
prepend your script with
exec >> /tmp/trace 2>&1 set -vx
that will dump anything visible into /tmp/trace
- -- Steffen Kaiser
Thank you for your continued assistance, Steffen.
You seem to be exactly correct with the Abort signal.
I prepended the values you suggested to the pipe script and here's the relevant output:
- /usr/lib/dovecot/deliver -d sa-training@example.com -m Training.SPAM ^A^H5584 prefix=lda: ^A^F5584 io_add(0x1) called twice fd=7, callback=0x7f23489fb6f0 -> 0x7f23489aa530
Unfortunately the only spot found is: http://dovecot.org/pipermail/dovecot/2012-May/135636.html
Is it the same fd=# always? Is it already open in your script? You could check with lsof -p $$
However, you should check if Dovecot v2.2.13 already fixes the problem.
-- Steffen Kaiser
So, I upgraded to Dovecot 2.2.13, and had to build the antispam plugin from source (because my distro doesn't provide pre-built binary packages for antispam that meet the dependency requirements for the Dovecot 2.2.13 packages that reside at http://xi.rename-it.nl/debian/).
The "make" script complained that "dovecot-config" could not be found. Well, from what I can determine, there is no file by this name in /usr/lib/dovecot/; the file name appears to be "config" (not "dovecot-config"). I created a symlink for the name that antispam was expecting and the build process succeeded. Not sure if there was a better way to deal with that, but it seemed to work, and everything seems to be up-and-running at this point.
Also, unless I'm mistaken, the "pipe" back-end for antispam has disappeared; I'm using mailtrain instead, which seems to work the same way.
Unfortunately, despite the valiant effort, the behavior is exactly the same; still seeing exit code status 134 whenever the antispam plugin fires. :(
And yes, Steffen, the fd=7 is always present and the same.
Dovecot tries to be admin-friendly. Common error messages are made as easily understandable as possible. Any crash, no matter how it happened, is considered a bug that will be fixed.
Have we reached this point yet?
Happy to try any other suggestions...
Thanks!
-Ben
On 8/8/2014 12:40 PM, Ben Johnson wrote:
Unfortunately, despite the valiant effort, the behavior is exactly the same; still seeing exit code status 134 whenever the antispam plugin fires. :(
And yes, Steffen, the fd=7 is always present and the same.
Dovecot tries to be admin-friendly. Common error messages are made as easily understandable as possible. Any crash, no matter how it happened, is considered a bug that will be fixed. Have we reached this point yet?
Happy to try any other suggestions...
Thanks!
-Ben
I'll submit a bug report once I'm able to capture the appropriate debugging information.
Thanks,
-Ben
On 2014-08-07 11:41, Ben Johnson wrote:
On 8/7/2014 11:14 AM, Steffen Kaiser wrote:
one idea: http://www.tldp.org/LDP/abs/html/exitcodes.html
exit code 134 would be in bash's meaning (if this website is correct all) some program died off signal 6. This would be Abort in Linux.
prepend your script with
exec >> /tmp/trace 2>&1 set -vx
that will dump anything visible into /tmp/trace
- -- Steffen Kaiser
Thank you for your continued assistance, Steffen.
You seem to be exactly correct with the Abort signal.
I prepended the values you suggested to the pipe script and here's the relevant output:
- /usr/lib/dovecot/deliver -d sa-training@example.com -m Training.SPAM ^A^H5584 prefix=lda: ^A^F5584 io_add(0x1) called twice fd=7, callback=0x7f23489fb6f0 -> 0x7f23489aa530 ^A^D5584 Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0x5e271) [0x7f23489e9271] -> /usr/lib/dovecot/libdovecot.so.0(+0x5e34e) [0x7f23489e934e] -> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7f23489a4a9e] -> /usr/lib/dovecot/libdovecot.so.0(ioloop_iolist_add+0x83) [0x7f23489f9533] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handle_add+0x3b) [0x7f23489f9cbb] -> /usr/lib/dovecot/libdovecot.so.0(io_add+0x9b) [0x7f23489f89fb] -> /usr/lib/dovecot/libdovecot.so.0(master_service_io_listeners_add+0x69) [0x7f23489a9e49] -> /usr/lib/dovecot/libdovecot.so.0(master_service_init_finish+0xb0) [0x7f23489a9f90] -> /usr/lib/dovecot/deliver(main+0x1cb) [0x7f234939269b] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f23485e6ec5] -> /usr/lib/dovecot/deliver(+0x31de) [0x7f23493931de] /usr/local/bin/sa-learn-pipe.sh: line 52: 5584 Aborted (core dumped) /usr/lib/dovecot/deliver -d "sa-training@example.com" -m "Training.$mode"
- echo 'Exit status was 134'
Does this tell us anything more?
I don't see any indication that apparmor is at play, as there is no profile that should apply in this context (and there is nothing in the relevant log file):
# service apparmor status apparmor module is loaded. 8 profiles are loaded. 8 profiles are in enforce mode. /sbin/dhclient /usr/bin/freshclam /usr/lib/NetworkManager/nm-dhcp-client.action /usr/lib/connman/scripts/dhclient-script /usr/sbin/clamd /usr/sbin/mysqld /usr/sbin/ntpd /usr/sbin/tcpdump 0 profiles are in complain mode. 4 processes have profiles defined. 4 processes are in enforce mode. /usr/bin/freshclam (2015) /usr/sbin/clamd (1897) /usr/sbin/mysqld (1239) /usr/sbin/ntpd (2472) 0 processes are in complain mode. 0 processes are unconfined but have a profile defined.
I'll try to reproduce this on an identically-configured server. I wonder if it would be worth changing the version of Dovecot. But I hate to play whack-a-mole if a more systematic approach is to be had.
Thanks again,
-Ben
Hello,
I am still struggling with this problem, and am wondering what the best course of action might be with regard to finding a solution.
This behavior is the same on two identically-configured Ubuntu 14.04 LTS servers. At least whatever the problem might be, it's consistent.
I realize that this version of Dovecot is a bit stale (2.2.9), but ultimately I am forced to work within official the Ubuntu repositories.
That said, for the sake of academia, I tried upgrading Dovecot to the latest "ee" version, to see if the problem still exists, but I receive an "ABI version mismatch" when I try to build the Antispam plugin from source. I posted to the mailing list about that and never did receive a response.
If it would be more appropriate to file a bug report on the Ubuntu Launchpad system, I am happy to do so.
Thank you for any further guidance,
-Ben
On -10.01.-28163 20:59, Ben Johnson wrote:
I have ensured that the pipe script is, in fact, being executed as the vmail user, by inserting the following into my debug output:
CURRENT_USER=$(whoami) echo "$CURRENT_USER"
This outputs "vmail".
FWIW, if a problem with identities and permissions is still a possibility, you should have a look at primary and secondary groups (e.g., output of "id" command) as well. And maybe also the data reported by "umask", "secon --self", ...
Regards, J. Bern
*NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
participants (4)
-
Ben Johnson
-
ben＠indietorrent.org
-
Jochen Bern
-
Steffen Kaiser