Segfaults after upgrade to Debian Jessie
Hi,
I've just upgrade from Debian Wheezy to Debian Jessie and am getting:
Fatal: master: service(lmtp): child 6761 killed with signal 11 (core dumped)
It seems to be something to do with sieve. When I disable that from lmtp then everything works fine.
OS: Debian Jessie Dovecot version: 2.2.13 CPU: x86
This is the gdb output:
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `dovecot/lmtp'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f8e4c94f626 in sieve_validator_register_command () from /usr/lib/dovecot/libdovecot-sieve.so.0
And dovecot -n
# 2.2.13: /etc/dovecot/dovecot.conf # OS: Linux 3.2.0-4-amd64 x86_64 Debian 8.1 ext3 auth_mechanisms = plain login dict { sieve = mysql:/etc/dovecot/pigeonhole-sieve.dict } mail_location = maildir:/var/mail/vhosts/%d/%n mail_privileged_group = mail 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 vnd.dovecot.extdata namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { driver = pam } passdb { args = /etc/dovecot/dovecot-sql.conf.ext driver = sql } plugin { sieve = dict:proxy::sieve;name=active sieve_dir = ~/sieve sieve_extdata_dict_uri = proxy::sieve sieve_plugins = sieve_extdata } protocols = " imap lmtp sieve" service auth-worker { user = vmail } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0666 user = postfix } unix_listener auth-userdb { mode = 0600 user = vmail } user = dovecot } service dict { unix_listener dict { mode = 0600 user = vmail } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } } ssl = required ssl_cert =
Any ideas?
Thanks,
Andy
On Sat, 2015-07-25 at 00:32 +0100, Andrew Beverley wrote:
Hi,
I've just upgrade from Debian Wheezy to Debian Jessie and am getting:
Fatal: master: service(lmtp): child 6761 killed with signal 11 (core dumped)
It seems to be something to do with sieve. When I disable that from lmtp then everything works fine.
OS: Debian Jessie Dovecot version: 2.2.13 CPU: x86
This is the gdb output:
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `dovecot/lmtp'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f8e4c94f626 in sieve_validator_register_command () from /usr/lib/dovecot/libdovecot-sieve.so.0
I've just tried upgrading to 2.2.18 (Stretch) but get the same error. I've opened a Debian bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794718
I have also tried downgrading to 2.1.7 (Wheezy) and everything works correctly.
Thanks,
Andy
Op 7/25/2015 om 1:32 AM schreef Andrew Beverley:
Hi,
I've just upgrade from Debian Wheezy to Debian Jessie and am getting:
Fatal: master: service(lmtp): child 6761 killed with signal 11 (core dumped)
It seems to be something to do with sieve. When I disable that from lmtp then everything works fine.
OS: Debian Jessie Dovecot version: 2.2.13 CPU: x86
This is the gdb output:
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `dovecot/lmtp'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f8e4c94f626 in sieve_validator_register_command () from /usr/lib/dovecot/libdovecot-sieve.so.0
Could you provide a full backtrace using the gdb command `bt full'?
Regards,
Stephan.
On Thu, 2015-08-06 at 09:12 +0200, Stephan Bosch wrote:
Could you provide a full backtrace using the gdb command `bt full'?
Thanks for the reply. Is this everything you need?
#0 0x00007f8553969626 in sieve_validator_register_command () from /usr/lib/dovecot/libdovecot-sieve.so.0 No symbol table info available. #1 0x00007f8552eff4e6 in ext_extdata_validator_load (ext=0x7f8556f60280, valdtr=0xffffffff) at ext-extdata.c:46 No locals. #2 0x00007f85539791a4 in sieve_extension_unregister () from /usr/lib/dovecot/libdovecot-sieve.so.0 No symbol table info available. #3 0x00007f855397950e in sieve_plugins_unload () from /usr/lib/dovecot/libdovecot-sieve.so.0 No symbol table info available. #4 0x00007f855397e8dc in sieve_deinit () from /usr/lib/dovecot/libdovecot-sieve.so.0 No symbol table info available. #5 0x00007f8553bc7948 in ?? () from /usr/lib/dovecot/modules/lib90_sieve_plugin.so No symbol table info available. #6 0x00007f855497ad69 in mail_deliver () from /usr/lib/dovecot/libdovecot-lda.so.0 No symbol table info available. #7 0x00007f8554daa171 in ?? () No symbol table info available. #8 0x00007f85543f4d0f in io_loop_call_io () from /usr/lib/dovecot/libdovecot.so.0 No symbol table info available. #9 0x00007f85543f5d09 in io_loop_handler_run_internal () from /usr/lib/dovecot/libdovecot.so.0 No symbol table info available. #10 0x00007f85543f4d79 in io_loop_handler_run () from /usr/lib/dovecot/libdovecot.so.0 No symbol table info available. #11 0x00007f85543f4df8 in io_loop_run () from /usr/lib/dovecot/libdovecot.so.0 No symbol table info available. #12 0x00007f855439fdc3 in master_service_run () from /usr/lib/dovecot/libdovecot.so.0 No symbol table info available. #13 0x00007f8554da89b5 in main ()
Op 8/6/2015 om 9:35 AM schreef Andrew Beverley:
On Thu, 2015-08-06 at 09:12 +0200, Stephan Bosch wrote:
Could you provide a full backtrace using the gdb command `bt full'? Thanks for the reply. Is this everything you need?
You have no debug symbols installed. Could you install dovecot-dbg package and try again?
Regards,
Stephan
On Thu, 2015-08-06 at 09:49 +0200, Stephan Bosch wrote:
You have no debug symbols installed. Could you install dovecot-dbg package and try again?
Sorry, how's this:
#0 sieve_validator_find_command_registration (valdtr=0xffffffff, command=0x7fc573c4bcd8 "extdata") at sieve-validator.c:309
No locals.
#1 sieve_validator_register_command (valdtr=0xffffffff, ext=0x7fc5761b1280, cmd_def=0x7fc573e4c400
What version of the extdata plugin are you using? This looks like a version built for Dovecot v2.1/Pigeonhole 0.3.0. Keep in mind that the extdata plugin is not part of the Pigeonhole distribution, so that will not be upgraded along with Pigeonhole.
Since the extdata plugin is not part of the normal Debian packages (not afaik anyway), you likely compiled and installed the extdata plugin manually in the past while using Dovecot 2.1. Do that again, but use this repository: http://hg.rename-it.nl/pigeonhole-0.4-sieve-extdata/
Regards,
Stephan.
Andrew Beverley schreef op 6-8-2015 om 10:13:
On Thu, 2015-08-06 at 09:49 +0200, Stephan Bosch wrote:
You have no debug symbols installed. Could you install dovecot-dbg package and try again? Sorry, how's this:
#0 sieve_validator_find_command_registration (valdtr=0xffffffff, command=0x7fc573c4bcd8 "extdata") at sieve-validator.c:309 No locals. #1 sieve_validator_register_command (valdtr=0xffffffff, ext=0x7fc5761b1280, cmd_def=0x7fc573e4c400
) at sieve-validator.c:331 cmd_reg = <optimized out> #2 0x00007fc573c4b4e6 in ext_extdata_validator_load (ext=0x7fc5761b1280, valdtr=0xffffffff) at ext-extdata.c:46 No locals. #3 0x00007fc5746c51a4 in _sieve_extension_unload (ext=<optimized out>) at sieve-extensions.c:316 No locals. #4 sieve_extension_unregister (ext=<optimized out>) at sieve-extensions.c:426 ext_reg = <optimized out> ext_id = <optimized out> #5 0x00007fc5746c550e in sieve_plugins_unload (svinst=0x7fc5761b09b0) at sieve-plugins.c:166 module = 0x7fc5761b5500 unload_func = <optimized out> plugin = 0x7fc5761b1268 __FUNCTION__ = "sieve_plugins_unload" #6 0x00007fc5746ca8dc in sieve_deinit (svinst=svinst@entry=0x7ffdd3a36050) at sieve.c:136 No locals. #7 0x00007fc574913948 in lda_sieve_deliver_mail (mdctx=<optimized out>, storage_r=0x7ffdd3a36208) at lda-sieve-plugin.c:948 srctx = {svinst = 0x7fc5761b09b0, mdctx = 0x7ffdd3a36230, home_dir = 0x7fc5761acf78 "/var/mail/vhosts/xx/yy", scripts = 0x7fc576171088, script_count = 0, user_script = 0x0, main_script = 0x0, msgdata = 0x0, scriptenv = 0x0, user_ehandler = 0x0, master_ehandler = 0x7fc5761b56c0, userlog = 0x0} debug = <optimized out> svenv = {hostname = 0x7fc57618cb98 "xx.com", domainname = 0x0, base_dir = 0x7fc5761ac8c0 "/var/run/dovecot", username = 0x7fc5761abda8 "yy@xx.com", home_dir = 0x7fc5761acf78 "/var/mail/vhosts/xx/yy", flags = SIEVE_FLAG_HOME_RELATIVE, location = SIEVE_ENV_LOCATION_MDA, delivery_phase = SIEVE_DELIVERY_PHASE_DURING} i = <optimized out> ret = <optimized out> #8 0x00007fc5756c6d69 in mail_deliver (ctx=ctx@entry=0x7ffdd3a36230, storage_r=storage_r@entry=0x7ffdd3a36208) at mail-deliver.c:400 ret = <optimized out> #9 0x00007fc575af6171 in client_deliver (session=0x7fc5761aa060, src_mail=0x7fc5761a5840, rcpt=0x7fc57617e7d0, client=0x7fc57617df50) at commands.c:689 lda_set = 0x7fc57618cb28 ns = <optimized out> set_parser = <optimized out> line = <optimized out> storage = 0x0 sets = <optimized out> mail_error = 1981272992 ret = <optimized out> dctx = {pool = 0x7fc5761aa040, set = 0x7fc57618cb28, session = 0x7fc5761aa060, dup_ctx = 0x7fc5761b08d0, session_id = 0x7fc57617e760 "8WveM2IVw1V5fgAAChoztw", src_mail = 0x7fc5761a5840, src_envelope_sender = 0x7fc57617e778 "xx@hotmail.com", dest_user = 0x7fc5761abcd0, dest_addr = 0x7fc57617edd0 "yy@xx.com", final_dest_addr = 0x7fc57617edd0 "yy@xx.com", dest_mailbox_name = 0x7fc575af8ad0 "INBOX", dest_mail = 0x0, var_expand_table = 0x0, tempfail_error = 0x0, tried_default_save = false, saved_mail = false, save_dest_mail = false, mailbox_full = false, dsn = false} input = <optimized out> mail_set = <optimized out> error = <optimized out> username = <optimized out> #10 client_deliver_next (session=0x7fc5761aa060, src_mail=0x7fc5761a5840, client=0x7fc57617df50) at commands.c:732 count = <optimized out> #11 client_input_data_write_local (input=<optimized out>, client=0x7fc57617df50) at commands.c:827 src_mail = 0x7fc5761a5840 first_uid = 4294967295 session = 0x7fc5761aa060 old_uid = 0 #12 client_input_data_write (client=0x7fc57617df50) at commands.c:939 input = 0x7fc57618dc50 ret = true #13 client_input_data_handle (client=0x7fc57617df50) at commands.c:1033 data = <optimized out> size = 934 ret = <optimized out> #14 0x00007fc575140d0f in io_loop_call_io (io=0x7fc57617d3a0) at ioloop.c:441 ioloop = 0x7fc576178730 t_id = 2 __FUNCTION__ = "io_loop_call_io" #15 0x00007fc575141d09 in io_loop_handler_run_internal (ioloop=ioloop@entry=0x7fc576178730) at ioloop-epoll.c:220 ctx = 0x7fc57617b550 io = <optimized out> tv = {tv_sec = 299, tv_usec = 983558} events_count = <optimized out> msecs = <optimized out> ret = 1 i = 0 j = <optimized out> call = <optimized out> __FUNCTION__ = "io_loop_handler_run_internal" #16 0x00007fc575140d79 in io_loop_handler_run (ioloop=ioloop@entry=0x7fc576178730) at ioloop.c:488 No locals. #17 0x00007fc575140df8 in io_loop_run (ioloop=0x7fc576178730) at ioloop.c:465 __FUNCTION__ = "io_loop_run" #18 0x00007fc5750ebdc3 in master_service_run (service=0x7fc5761785c0, callback=<optimized out>) at master-service.c:566 No locals. #19 0x00007fc575af49b5 in main (argc=1, argv=0x7fc576178390) at main.c:122 set_roots = {0x7fc5758ca4c0 , 0x7fc575cfa6c0 , 0x0} service_flags = <optimized out> storage_service_flags = <optimized out> c = <optimized out>
On Thu, 2015-08-06 at 16:10 +0200, Stephan Bosch wrote:
What version of the extdata plugin are you using? This looks like a version built for Dovecot v2.1/Pigeonhole 0.3.0. Keep in mind that the extdata plugin is not part of the Pigeonhole distribution, so that will not be upgraded along with Pigeonhole.
Since the extdata plugin is not part of the normal Debian packages (not afaik anyway), you likely compiled and installed the extdata plugin manually in the past while using Dovecot 2.1. Do that again, but use this repository: http://hg.rename-it.nl/pigeonhole-0.4-sieve-extdata/
You're absolutely right; sorry, I had completely forgotten. I'll give that a go and let you know how I get on.
Thanks,
Andy
On Thu, 2015-08-06 at 16:10 +0200, Stephan Bosch wrote:
Since the extdata plugin is not part of the normal Debian packages (not afaik anyway), you likely compiled and installed the extdata plugin manually in the past while using Dovecot 2.1. Do that again, but use this repository: http://hg.rename-it.nl/pigeonhole-0.4-sieve-extdata/
I'm just trying to install this now, but am getting the following compilation error:
make[2]: Entering directory '/usr/src/pigeonhole-0-4-sieve-extdata-4ce3912ee200/src' /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/include/dovecot -I/usr/include/dovecot/sieve -DPKG_RUNDIR=\"""\" -std=gnu99 -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -MT sieve-extdata-plugin.lo -MD -MP -MF .deps/sieve-extdata-plugin.Tpo -c -o sieve-extdata-plugin.lo sieve-extdata-plugin.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/include/dovecot -I/usr/include/dovecot/sieve -DPKG_RUNDIR=\"\" -std=gnu99 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -MT sieve-extdata-plugin.lo -MD -MP -MF .deps/sieve-extdata-plugin.Tpo -c sieve-extdata-plugin.c -fPIC -DPIC -o .libs/sieve-extdata-plugin.o sieve-extdata-plugin.c:20:44: error: 'PIGEONHOLE_ABI_VERSION' undeclared here (not in a function) const char *sieve_extdate_plugin_version = PIGEONHOLE_ABI_VERSION;
This is on Debian Jessie using:
./configure --with-dovecot=/usr/lib/dovecot/ --with-pigeonhole=/usr/include/dovecot/sieve/
The headers seem to be found correctly when using configure, it's just when compiling that I get an error.
pigeonhole-0-4-sieve-extdata-4ce3912ee200
Any ideas?
Thanks,
Andy
Andrew Beverley schreef op 17-8-2015 om 14:05:
On Thu, 2015-08-06 at 16:10 +0200, Stephan Bosch wrote:
Since the extdata plugin is not part of the normal Debian packages (not afaik anyway), you likely compiled and installed the extdata plugin manually in the past while using Dovecot 2.1. Do that again, but use this repository: http://hg.rename-it.nl/pigeonhole-0.4-sieve-extdata/ I'm just trying to install this now, but am getting the following compilation error:
make[2]: Entering directory '/usr/src/pigeonhole-0-4-sieve-extdata-4ce3912ee200/src' /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/include/dovecot -I/usr/include/dovecot/sieve -DPKG_RUNDIR=\"""\" -std=gnu99 -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -MT sieve-extdata-plugin.lo -MD -MP -MF .deps/sieve-extdata-plugin.Tpo -c -o sieve-extdata-plugin.lo sieve-extdata-plugin.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/include/dovecot -I/usr/include/dovecot/sieve -DPKG_RUNDIR=\"\" -std=gnu99 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -MT sieve-extdata-plugin.lo -MD -MP -MF .deps/sieve-extdata-plugin.Tpo -c sieve-extdata-plugin.c -fPIC -DPIC -o .libs/sieve-extdata-plugin.o sieve-extdata-plugin.c:20:44: error: 'PIGEONHOLE_ABI_VERSION' undeclared here (not in a function) const char *sieve_extdate_plugin_version = PIGEONHOLE_ABI_VERSION;
This is on Debian Jessie using:
./configure --with-dovecot=/usr/lib/dovecot/ --with-pigeonhole=/usr/include/dovecot/sieve/
The headers seem to be found correctly when using configure, it's just when compiling that I get an error.
pigeonhole-0-4-sieve-extdata-4ce3912ee200
Any ideas?
Yes. I prepared for preventing your problem by adding ABI version support (much like Dovecot itself already has for its plugins). This is the last change in the pigeonhole-0.4-sieve-extdata plugin repository.
There is no Pigeonhole release for this yet (and adoption in Debian will likely take some time), but until then you can avoid this by using the the exdata hg revision before tip (57c8d3e6b562).
Regards,
Stephan.
On Mon, 2015-08-17 at 14:13 +0200, Stephan Bosch wrote:
but until then you can avoid this by using the the exdata hg revision before tip (57c8d3e6b562).
Great, thanks for the quick reply, that fixed the compilation problem.
I'm still getting a segfault though. This time the backtrace is:
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `dovecot/lmtp'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 sieve_validator_find_command_registration (valdtr=0xffffffff, command=0x7ff53d612cd8 "extdata") at sieve-validator.c:309
309 sieve-validator.c: No such file or directory.
(gdb) bt full
#0 sieve_validator_find_command_registration (valdtr=0xffffffff, command=0x7ff53d612cd8 "extdata") at sieve-validator.c:309
No locals.
#1 sieve_validator_register_command (valdtr=0xffffffff, ext=0x7ff53fb5a280, cmd_def=0x7ff53d813400
Andrew Beverley schreef op 17-8-2015 om 14:35:
On Mon, 2015-08-17 at 14:13 +0200, Stephan Bosch wrote:
but until then you can avoid this by using the the exdata hg revision before tip (57c8d3e6b562). Great, thanks for the quick reply, that fixed the compilation problem.
I'm still getting a segfault though. This time the backtrace is:
Still looks like the executed extdata plugin was compiled against a different pigeonhole. That validator_load function is called inappropriately from extension_unload. Are you sure that the plugin is installed and the old one is not present anymore?
Regards,
Stephan.
On Mon, 2015-08-17 at 15:23 +0200, Stephan Bosch wrote:
Still looks like the executed extdata plugin was compiled against a different pigeonhole.
Got it. There was an old version in /usr/lib/dovecot/modules/sieve/, whereas the new one was installed into /usr/local/lib/dovecot/sieve/. That all works now, and no segfault. Thanks for all your help and patience.
Unfortunately my vacation rule no longer works though. I'm getting "sieve: user's script dict:proxy::sieve;name=active doesn't exist (trying default script location instead)"
I have a dict:proxy configured (/etc/dovecot/pigeonhole-sieve.dict):
connect = host=127.0.0.1 dbname=postfix user=postfix password=xxx
map { pattern = priv/sieve/name/$script_name table = virtual_users username_field = email value_field = sieve_id fields { sieve_active = $script_name } }
And that added to dovecot.conf:
dict { sieve = mysql:/etc/dovecot/pigeonhole-sieve.dict }
And that in 90-sieve.conf:
plugin { sieve = dict:proxy::sieve;name=active }
I guess I'm doing something stupid. Any ideas?
Thanks,
Andy
Andrew Beverley schreef op 17-8-2015 om 16:50:
On Mon, 2015-08-17 at 15:23 +0200, Stephan Bosch wrote:
Still looks like the executed extdata plugin was compiled against a different pigeonhole. Got it. There was an old version in /usr/lib/dovecot/modules/sieve/, whereas the new one was installed into /usr/local/lib/dovecot/sieve/. That all works now, and no segfault. Thanks for all your help and patience.
Unfortunately my vacation rule no longer works though. I'm getting "sieve: user's script dict:proxy::sieve;name=active doesn't exist (trying default script location instead)" [...] I guess I'm doing something stupid. Any ideas?
Could you enable mail_debug and look at your log output? That should show some more details of what it is doing.
Regards,
Stephan.
On Mon, 2015-08-17 at 17:37 +0200, Stephan Bosch wrote:
Unfortunately my vacation rule no longer works though. I'm getting "sieve: user's script dict:proxy::sieve;name=active doesn't exist (trying default script location instead)" [...] I guess I'm doing something stupid. Any ideas?
Could you enable mail_debug and look at your log output? That should show some more details of what it is doing.
I've fixed this by changing the name of the sieve script in the database from "active" to "main script". I'm a bit confused by this though.
I could see this in the log:
Aug 17 23:28:54 fieri dovecot: lmtp(10285, x@x.com): Debug: yxlyGzZu0lUtKAAAChoztw: sieve: sieve dict backend: user=x@x.com, uri=proxy::sieve, script=main script Aug 17 23:28:54 fieri dovecot: lmtp(10285, x@x.com): Debug: yxlyGzZu0lUtKAAAChoztw: sieve: sieve dict backend: script `main script' not found at path priv/sieve/name/main script Aug 17 23:28:54 fieri dovecot: lmtp(10285, x@x.com): Debug: yxlyGzZu0lUtKAAAChoztw: sieve: user's script dict:proxy::sieve;name=active doesn't exist (trying default script location instead) Aug 17 23:28:54 fieri dovecot: lmtp(10285, x@x.com): Debug: yxlyGzZu0lUtKAAAChoztw: sieve: no default script configured for user Aug 17 23:28:54 fieri dovecot: lmtp(10285, x@x.com): Debug: yxlyGzZu0lUtKAAAChoztw: sieve: user has no valid location for a personal script Aug 17 23:28:54 fieri dovecot: lmtp(10285, x@x.com): Debug: yxlyGzZu0lUtKAAAChoztw: sieve: no scripts to execute: reverting to default delivery.
So it's looking first for "main script", which is why it now works. But it was then looking for "dict:proxy::sieve;name=active". Why didn't that work when I have this in my sieve config?
plugin { sieve = dict:proxy::sieve;name=active }
I also don't understand why it is looking for "main script" rather than "active" at all, and why things stopped working when I upgraded.
Sorry for all the questions - I'll be happy to update the wiki once I've understood things better.
Thanks for all your help,
Andy
Op 8/18/2015 om 2:04 AM schreef Andrew Beverley:
On Mon, 2015-08-17 at 17:37 +0200, Stephan Bosch wrote:
Unfortunately my vacation rule no longer works though. I'm getting "sieve: user's script dict:proxy::sieve;name=active doesn't exist (trying default script location instead)" [...] I guess I'm doing something stupid. Any ideas? Could you enable mail_debug and look at your log output? That should show some more details of what it is doing. I've fixed this by changing the name of the sieve script in the database from "active" to "main script". I'm a bit confused by this though.
I could see this in the log:
Aug 17 23:28:54 fieri dovecot: lmtp(10285, x@x.com): Debug: yxlyGzZu0lUtKAAAChoztw: sieve: sieve dict backend: user=x@x.com, uri=proxy::sieve, script=main script Aug 17 23:28:54 fieri dovecot: lmtp(10285, x@x.com): Debug: yxlyGzZu0lUtKAAAChoztw: sieve: sieve dict backend: script `main script' not found at path priv/sieve/name/main script Aug 17 23:28:54 fieri dovecot: lmtp(10285, x@x.com): Debug: yxlyGzZu0lUtKAAAChoztw: sieve: user's script dict:proxy::sieve;name=active doesn't exist (trying default script location instead) Aug 17 23:28:54 fieri dovecot: lmtp(10285, x@x.com): Debug: yxlyGzZu0lUtKAAAChoztw: sieve: no default script configured for user Aug 17 23:28:54 fieri dovecot: lmtp(10285, x@x.com): Debug: yxlyGzZu0lUtKAAAChoztw: sieve: user has no valid location for a personal script Aug 17 23:28:54 fieri dovecot: lmtp(10285, x@x.com): Debug: yxlyGzZu0lUtKAAAChoztw: sieve: no scripts to execute: reverting to default delivery.
So it's looking first for "main script", which is why it now works. But it was then looking for "dict:proxy::sieve;name=active". Why didn't that work when I have this in my sieve config?
plugin { sieve = dict:proxy::sieve;name=active }
I also don't understand why it is looking for "main script" rather than "active" at all, and why things stopped working when I upgraded.
Sorry for all the questions - I'll be happy to update the wiki once I've understood things better.
Unfortunately, Jessie is stuck at a very old version of Pigeonhole which has this problem.
Regards,
Stephan.
participants (2)
-
Andrew Beverley
-
Stephan Bosch