Exit status code 134; what is it, in the context of Dovecot Antispam plug-in?

[Ben Johnson]

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 at 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 at 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 at 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 = </root/ssl/example.com/example.com.crt
ssl_key = </root/ssl/example.com/example.com.key
userdb {
args = /etc/dovecot/dovecot-sql.conf
driver = sql
}
protocol imap {
mail_plugins = quota imap_quota antispam
}
protocol pop3 {
mail_plugins = quota
pop3_uidl_format = %08Xu%08Xv
}
protocol lda {
info_log_path =
log_path =
mail_plugins = sieve quota
}

[Steffen Kaiser]

Post by Ben Johnson
I have some debugging output in my pipe script; the output looks

How does your script looks like?

Post by Ben Johnson
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 at 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.

Post by Ben Johnson
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
# su -c '/usr/lib/dovecot/deliver -d "sa-training at 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

[Ben Johnson]

Post by Steffen Kaiser

Post by Ben Johnson
I have some debugging output in my pipe script; the output looks

How does your script looks like?

http://pastebin.com/nh8SwQtw

Post by Steffen Kaiser

Post by Ben Johnson
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 at 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.

Post by Steffen Kaiser

Post by Ben Johnson
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
# su -c '/usr/lib/dovecot/deliver -d "sa-training at 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

[Ben Johnson]

Post by Ben Johnson

Post by Steffen Kaiser

Post by Ben Johnson
I have some debugging output in my pipe script; the output looks

How does your script looks like?

http://pastebin.com/nh8SwQtw

Post by Steffen Kaiser

Post by Ben Johnson
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 at 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.

Post by Steffen Kaiser

Post by Ben Johnson
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
# su -c '/usr/lib/dovecot/deliver -d "sa-training at 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 at 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 at 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

[Steffen Kaiser]

Post by Ben Johnson

Post by Ben Johnson

Post by Steffen Kaiser

Post by Ben Johnson
I have some debugging output in my pipe script; the output looks

How does your script looks like?

http://pastebin.com/nh8SwQtw

Post by Steffen Kaiser

Post by Ben Johnson
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 at 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.

Post by Steffen Kaiser

Post by Ben Johnson
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
# su -c '/usr/lib/dovecot/deliver -d "sa-training at 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.

Post by Ben Johnson

Post by Ben Johnson
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
/usr/lib/dovecot/deliver -d "sa-training at 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,
# su vmail
$ whoami
vmail
$ /usr/lib/dovecot/deliver -d "sa-training at 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
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

[Ben Johnson]

Post by Steffen Kaiser
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 at 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 at 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]

Post by Ben Johnson

Post by Steffen Kaiser
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
+ /usr/lib/dovecot/deliver -d sa-training at example.com -m Training.SPAM
^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.

Post by Ben Johnson
^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 at 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
# 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

[Ben Johnson]

Post by Steffen Kaiser

Post by Ben Johnson

Post by Steffen Kaiser
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
+ /usr/lib/dovecot/deliver -d sa-training at example.com -m
Training.SPAM ^A^H5584 prefix=lda: ^A^F5584 io_add(0x1) called
twice fd=7, callback=0x7f23489fb6f0 -> 0x7f23489aa530

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.

Post by Steffen Kaiser
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

[Ben Johnson]

Post by Ben Johnson
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.

Post by Steffen Kaiser
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

[ben]

Post by Ben Johnson

Post by Steffen Kaiser
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
+ /usr/lib/dovecot/deliver -d sa-training at example.com -m Training.SPAM
^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 at 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
# 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

[Jochen Bern]

Post by Ben Johnson
I have ensured that the pipe script is, in fact, being executed as the
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