dovecot-pigeonhole running external script ends with signal 11
Stephan Bosch
stephan at rename-it.nl
Tue Jan 3 20:12:47 UTC 2017
Op 1/3/2017 om 4:28 PM schreef Tobi:
> I have no idea why the manual call runs perfect and the call from sieve
> file ends up in this error.
> Does anyone have an idea how I could narrow down the source of this
> error? Or even better how to fix it? :-)
In the most likely scenario, there is some sort of bug in one of the
programs your script invokes or even the shell running the script.
Still, it is possible that Dovecot is causing this in the brief moment
after the child process is forked and before actual script is executed.
Since you're using LMTP, you could try to run the lmtp service from
command line in GDB. In essence, this looks as follows (you will need to
run this as the mail user, e.g. vmail, or you can run it as root):
$ gdb --args /usr/lib/dovecot/lmtp
<verbose GDB output/>
Reading symbols from /usr/lib/dovecot/lmtp...done.
(gdb) set follow-fork-mode child
(gdb) r
Starting program: /usr/lib/dovecot/lmtp
process 63910 is executing new program: /usr/bin/doveconf
process 63910 is executing new program: /usr/lib/dovecot/lmtp
Debug: none: root=, index=, indexpvt=, control=, inbox=, alt=
220 johanna.johanna.tds Dovecot ready.
Info: Connect from local
lhlo frop
250-johanna.johanna.tds
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING
mail from:<stephan at rename-it.nl>
250 2.1.0 OK
rcpt to:<user>
250 2.1.5 OK
data
354 OK
<message>
.
After the message is submitted, it should segfault. GDB will tell you
where this happened. If it happens in Dovecot somewhere, you should
obtain a back trace using `bt full`. If some other software is involved,
those developers would also likely need that back trace to find the
underlying problem.
Regards,
Stephan.
More information about the dovecot
mailing list