Re: [Dovecot] Make install error
On Fri, 2013-04-19 at 11:50 +0800, kengheng wrote: Hi, I'm recompiling dovecot 2.2.0/2.2.1 with error below during make install: test -z /usr/local/dovecot/lib/dovecot/auth || /usr/bin/mkdir -p /usr/local/dovecot/lib/dovecot/auth /usr/bin/mkdir: cannot create directory ‘/usr/local/dovecot/lib/dovecot/auth’: File exists This file shouldn't exist. The target Svr OS: OpenSuse 12.2 x86 and installed success for qmail/vpopmail. The configuration for dovecot as below: ./configure \ --prefix=/usr/local/dovecot \ --with-vpopmail \ --with-docs \ --with-ssl \ --without-shadow \ --without-pam \ --without-ldap \ --without-pgsql \ --without-sql \ --without-mysql \ --without-sqlite I think there's an older differently installed Dovecot in there. rm -rf /usr/local/dovecot/lib and try make install again.
Re: [Dovecot] Dovecot 2.1.16: default_client_count written to the logs
On Mon, 2013-04-22 at 14:07 +0200, Axel Luttgens wrote: Hello, As to be expected with low system limits, a warning may be written to the logs: master: Warning: fd limit (ulimit -n) is lower than required under max. load (256 1000), because of default_client_count Shouldn't it read default_client_limit instead of default_client_count? Yes, fixed. It seems that the warning is written only when reloading Dovecot, not upon Dovecot's startup. Is this deliberate? At startup it only goes to stderr, which I guess your init script hides. Although it would be nice if it logged it also.. I'll see about changing that.
Re: [Dovecot] Replication -- multiple users, three or more servers?
On Mon, 2013-04-22 at 11:23 -0700, Rich Wales wrote:
I'm running Dovecot 2.2.1 on an Ubuntu 12.04.2 server, with half a dozen
accounts for various family members. I want to set up replication
involving at least three Ubuntu servers, with different users replicated
on different sets of servers.
For example, I might have mail for user1 replicated on server1,
server2, and server3...
while mail for user2 would be on server1 and server2...
and mail for user3 would be on server1 and server3.
I've read the wiki page (http://wiki2.dovecot.org/Replication), but I'm
still confused. I'd love to see an example that clearly shows how to
set up specific individual mail users to be replicated on a different
set of servers for each user, like what I described above.
Everything is the same as in that wiki page, except you need to have
userdb field override the mail_replica setting. Or I guess you wouldn't
want to have a default mail_replica at all, so users won't accidentally
get replicated to wrong place. See
http://wiki2.dovecot.org/UserDatabase/ExtraFields
For example with SQL something like:
user_query = SELECT home, uid, gid, \
concat('tcp:', replicahost) as mail_replica \
FROM users WHERE userid = '%u'
Re: [Dovecot] Using dsync to export mail to remote IMAP account
On Mon, 2013-04-22 at 19:56 -0700, Joseph Tam wrote: I've read the web/man pages on dsync, but it's not clear to me whether dsync can be used to export (rather than import) a user's mailbox to a remote non-dovecot IMAP account. It should be possible at some point, but currently probably won't work very well. I got this error: dsync(localuser): Error: user localuser: Initialization failed: Namespace '': Unknown mail storage driver imapc dsync(localuser): Fatal: User init failed But this looks like you simply haven't compiled Dovecot with imapc support. See if dovecot --build-options|grep storage returns imapc.
[Dovecot] imap Panic: file istream-seekable.c: line 253 (i_stream_seekable_read): assertion failed: (stream-istream.v_offset + stream-pos = sstream-write_peak)
Hi Timo,
just another crash - using 2.2.1 (c95cea6e1389).
Regards,
Pascal
Reading symbols from /usr/local/libexec/dovecot/imap...done.
[New LWP 15198]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Core was generated by `dovecot/imap'.
Program terminated with signal 6, Aborted.
#0 0x7fea0d3a0475 in *__GI_raise (sig=optimized out) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
Already logging to gdb.txt.
#0 0x7fea0d3a0475 in *__GI_raise (sig=optimized out) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
pid = optimized out
selftid = optimized out
#1 0x7fea0d3a36f0 in *__GI_abort () at abort.c:92
act = {__sigaction_handler = {sa_handler = 0x7fff5fba6bd0, sa_sigaction
= 0x7fff5fba6bd0}, sa_mask = {__val = {140643224991072, 140643224986893,
140734799440880, 140643225264237, 140643227545232, 140643220802464,
140643233288192, 140643228326759, 4294967295, 206158430224, 1, 3048496, 0, 0,
0,
140643224485888}}, sa_flags = 232077810, sa_restorer =
0x5d6139330001}
sigs = {__val = {32, 0 repeats 15 times}}
#2 0x7fea0d772231 in default_fatal_finish (type=LOG_TYPE_PANIC, status=0)
at failures.c:191
backtrace = 0xca4020 /usr/local/lib/dovecot/libdovecot.so.0(+0x7a20a)
[0x7fea0d77220a] - /usr/local/lib/dovecot/libdovecot.so.0(+0x7b535)
[0x7fea0d773535] - /usr/local/lib/dovecot/libdovecot.so.0(i_fatal+0)
[0x7fea0d772...
#3 0x7fea0d773535 in i_internal_fatal_handler (ctx=0x7fff5fba6d70,
format=0x7fea0d7b83a0 file %s: line %d (%s): assertion failed: (%s),
args=0x7fff5fba6d58) at failures.c:652
status = 0
#4 0x7fea0d77250d in i_panic (format=0x7fea0d7b83a0 file %s: line %d
(%s): assertion failed: (%s)) at failures.c:263
ctx = {type = LOG_TYPE_PANIC, exit_status = 0, timestamp = 0x0}
args = {{gp_offset = 40, fp_offset = 48, overflow_arg_area =
0x7fff5fba6e40, reg_save_area = 0x7fff5fba6d80}}
#5 0x7fea0d786bb8 in i_stream_seekable_read (stream=0xd658a0) at
istream-seekable.c:253
sstream = 0xd658a0
data = 0x7fff5fba6ea0 \320n\272_\377\177
size = 14047392
pos = 27457
ret = 139638205298784
__FUNCTION__ = i_stream_seekable_read
#6 0x7fea0d77e866 in i_stream_read (stream=0xd65900) at istream.c:149
_stream = 0xd658a0
old_size = 0
ret = 140643225038704
__FUNCTION__ = i_stream_read
#7 0x7fea0d784c6f in i_stream_limit_read (stream=0xd39d00) at
istream-limit.c:50
lstream = 0xd39d00
left = 140643225038704
ret = 14047488
pos = 0
__FUNCTION__ = i_stream_limit_read
#8 0x7fea0d77e866 in i_stream_read (stream=0xd39d60) at istream.c:149
_stream = 0xd39d00
old_size = 0
ret = 13868288
__FUNCTION__ = i_stream_read
#9 0x7fea0d77ebf9 in i_stream_read_copy_from_parent (istream=0xd39f00) at
istream.c:193
stream = 0xd39ea0
pos = 0
ret = 13868288
__FUNCTION__ = i_stream_read_copy_from_parent
#10 0x7fea0daa1b67 in i_stream_mail_read (stream=0xd39ea0) at
istream-mail.c:67
mstream = 0xd39ea0
size = 13868384
ret = 13254133
#11 0x7fea0d77e866 in i_stream_read (stream=0xd39f00) at istream.c:149
_stream = 0xd39ea0
old_size = 0
ret = 140643221218978
__FUNCTION__ = i_stream_read
#12 0x7fea0d782fc9 in i_stream_crlf_read_common (cstream=0xd5e440) at
istream-crlf.c:22
stream = 0xd5e440
size = 0
avail = 13254247
ret = 0
__FUNCTION__ = i_stream_crlf_read_common
#13 0x7fea0d7830d1 in i_stream_crlf_read_crlf (stream=0xd5e440) at
istream-crlf.c:46
cstream = 0xd5e440
data = 0xd39ea0 \002
ptr = 0xd39ea0 \002
src = 0x7fff Address 0x7fff out of bounds
src_end = 0xd39f00 Ak
dest = 0xd39f00 Ak
dest_end = 0x0
size = 0
copy_len = 27457
ret = 140734799442160
__FUNCTION__ = i_stream_crlf_read_crlf
#14 0x7fea0d77e866 in i_stream_read (stream=0xd5e4a0) at istream.c:149
_stream = 0xd5e440
old_size = 0
ret = 140643225038704
__FUNCTION__ = i_stream_read
#15 0x7fea0d784c6f in i_stream_limit_read (stream=0xd5e5e0) at
istream-limit.c:50
lstream = 0xd5e5e0
left = 140643225038704
ret = 14017696
pos = 0
__FUNCTION__ = i_stream_limit_read
#16 0x7fea0d77e866 in i_stream_read (stream=0xd5e640) at istream.c:149
_stream = 0xd5e5e0
old_size = 0
ret = -6697839139754035552
__FUNCTION__ = i_stream_read
#17 0x7fea0d77f75b in i_stream_read_data (stream=0xd5e640,
data_r=0x7fff5fba7258, size_r=0x7fff5fba7268, threshold=8191) at
Re: [Dovecot] Integrate mbox into mdbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 20 Apr 2013, lutz.niede...@gmx.net wrote: I have several mbox files (unstructured, only the big plain mbox files) and I would like to integrate/read these mbox files into mdbox subfolders of specific users. This is a production system and I don't want to disturb running services and I am a bit afraid of not using the right command and maybe destroying (or whatever) their mailboxes. I am sure it is pretty easy. Can someone please tell me the correct dsync command line that I should use to read each mbox file (one-way) into the specific folder of the mdbox folder structure of a specific user? what Dovecot version do you have? doveadm help import might do what you want. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUXaAdF3r2wJMiz2NAQLuaAf+P3B81+32fQ/35n+Vt8lWQWo1jCdAyhPB qP837o3FMwbYhOBxF99VLZDLrB09SQE6s/677QW5yTuFZnWIyWZRRYRWYPXXKCzv qaPp1LoNX+YrdR14eaq1knh4XpF3S9bvd/cb1pPVP3s0yggzLiKcyTeSzamugvFl AlFgRcDYEK+GKqwOV6w5Mg47wb0yKEFYQkWY6x5rtqTY5/XaqsvcGPBNw89U4h2w xUJcPx+lT3nI500M5IbikY1sr1rPv2XJRrngFlBbaf/hNFuFFf4H1WhKO3H06I7F miXmTs2h9u8N1ysRq/uqCZGEc2gkg1gaTGke5hMa5b53D9AvB8rZGA== =KPWK -END PGP SIGNATURE-
[Dovecot] Dovecot 2.2.1: typo in src/lib-http/Makefile.in
Hello, there seems to be a typo in the dovecot-2.2.1-sources: in dovecot-2.2.1/src/lib-http/Makefile.in at line 758 the two lines ../lib-test/libtest.la \ ../lib/liblib.la do not fit into the Makefile-syntax. At compile-time they produce the error make: Fatal error in reader: Makefile, line 725: Unexpected end of line seen If I remove these two lines, everything compiles fine. Could you please check this. Thanks, Andreas -- Dr. Andreas Piper, Hochschulrechenzentrum der Philipps-Univ. Marburg Hans-Meerwein-Straße, 35032 Marburg, Germany Phone: +49 6421 28-23521 Fax: -26994 E-Mail: pi...@hrz.uni-marburg.de
Re: [Dovecot] Dovecot 2.1.16: default_client_count written to the logs
Le 23 avr. 2013 à 12:37, Timo Sirainen a écrit : On Mon, 2013-04-22 at 14:07 +0200, Axel Luttgens wrote: Hello, [...] Shouldn't it read default_client_limit instead of default_client_count? Yes, fixed. Thanks, Timo. It seems that the warning is written only when reloading Dovecot, not upon Dovecot's startup. Is this deliberate? At startup it only goes to stderr, which I guess your init script hides. Indeed, stdout/stderr are ignored by default for daemons started by launchd (one could specify file paths for those outputs, at the expense of some fds). Although it would be nice if it logged it also.. I'll see about changing that. Probably not a high priority one, but... yes, would be nice to have such warnings logged as well at startup. Best regards, Axel
Re: [Dovecot] Dovecot 2.2.1: typo in src/lib-http/Makefile.in
On 23.4.2013, at 15.56, Piper Andreas pi...@hrz.uni-marburg.de wrote: there seems to be a typo in the dovecot-2.2.1-sources: in dovecot-2.2.1/src/lib-http/Makefile.in at line 758 the two lines ../lib-test/libtest.la \ ../lib/liblib.la do not fit into the Makefile-syntax. At compile-time they produce the error make: Fatal error in reader: Makefile, line 725: Unexpected end of line seen Fixed: http://hg.dovecot.org/dovecot-2.2/rev/43e7606b31e2
Re: [Dovecot] Running LMTP as a user other than the root user
Le 16 avr. 2013 à 19:47, Axel Luttgens a écrit : [...] Mea culpa. I missed a few enlightening lines in 10-master.conf, at the beginning of the service auth section. They are terribly useful for understanding the coding choices and to conclude that everything works as intended. Axel
Re: [Dovecot] imap Panic: file istream-seekable.c: line 253 (i_stream_seekable_read): assertion failed: (stream-istream.v_offset + stream-pos = sstream-write_peak)
On 23.4.2013, at 14.47, Pascal Volk user+dove...@localhost.localdomain.org wrote: just another crash - using 2.2.1 (c95cea6e1389). Fixed: http://hg.dovecot.org/dovecot-2.2/rev/2784b88a4260 (This started happening only after yesterday's zlib change.)
[Dovecot] Feature request: Configure CONFIG_MODULE_DIR and AUTH_MODULE_DIR at runtime
Hi!
I am running dovecot 2.1.16 on NixOS (http://nixos.org), and I have been
fighting the dynamically loaded dovecot modules/plugins a bit.
The problem is that in Nix/NixOS all packages are completely isolated from
each other (each package has a separate /lib, /libexec, /bin etc, with
only its own files in it). So dovecot has all its modules under
/nix/store/xxx-dovecot/{lib,libexec}/dovecot, and the Pigeonhole modules
are under /nix/store/yyy-pidgeonhole/{lib,libexec}/dovecot.
Now, dovecot wants to load modules only from one directory, so I created a
virtual package that unifies all modules in
/nix/store/zzz-dovecot-plugins/{lib,libexec}/dovecot. I can then use this
directory as the mail_plugin_dir setting in dovecot.conf. This works
fine, dovecot can then find the sieve mail plugin.
The problem is the service and auth modules, that dovecot tries to load
from the compile-time set MODULE_DIR/{settings,auth}. This is a problem
for me, because I can't set the module path during compilation since that
introduces a circular dependency between the dovecot package and the
virtual dovecot-plugins package.
I have solved this by hacking dovecot to read an environment variable,
DOVECOT_CONFIG_MODULE_DIR, in the config_parse_load_modules function. This
way I can inject my module path during runtime. But this only works for
the master process, not the config process which seems to reset its
environment (I assume it does this when dropping privileges). So I did
another hack which lets me pass an argument to the config process which
contains the module path. I can then set this argument in dovecot.conf by
service config { executable = config /my/module/path }.
These hacks work, and I can now use both the sieve mail plugin and the
sieve service. I have attached the patch, but this is not a request to add
it to the source. My hack is a hack because I don't know enough about the
inner workings of dovecot to solve it in a good way. Rather, I'm asking
for some way to configure the module path in dovecot, either as an
argument to the master process or as a setting in dovecot.conf. A bonus
would be the ability to specify several paths that dovecot would search,
then I can do away with my virtual module package.
Best regards,
Rickard Nilsson
module_dir.patch
Description: Binary data
Re: [Dovecot] Feature request: Configure CONFIG_MODULE_DIR and AUTH_MODULE_DIR at runtime
On 23.4.2013, at 17.58, Rickard Nilsson rickard.nils...@telia.com wrote:
I am running dovecot 2.1.16 on NixOS (http://nixos.org), and I have been
fighting the dynamically loaded dovecot modules/plugins a bit.
The problem is that in Nix/NixOS all packages are completely isolated from
each other (each package has a separate /lib, /libexec, /bin etc, with only
its own files in it). So dovecot has all its modules under
/nix/store/xxx-dovecot/{lib,libexec}/dovecot, and the Pigeonhole modules are
under /nix/store/yyy-pidgeonhole/{lib,libexec}/dovecot.
Now, dovecot wants to load modules only from one directory, so I created a
virtual package that unifies all modules in
/nix/store/zzz-dovecot-plugins/{lib,libexec}/dovecot. I can then use this
directory as the mail_plugin_dir setting in dovecot.conf. This works fine,
dovecot can then find the sieve mail plugin.
The problem is the service and auth modules, that dovecot tries to load from
the compile-time set MODULE_DIR/{settings,auth}. This is a problem for me,
because I can't set the module path during compilation since that introduces
a circular dependency between the dovecot package and the virtual
dovecot-plugins package.
Sounds like a rather generic problem in nixos. Maybe there could be generic way
to handle this for other packages too, like maybe creating a whole new
directory somewhere (e.g. under /var) that has symlinks to all the installed
plugins?
I have solved this by hacking dovecot to read an environment variable,
DOVECOT_CONFIG_MODULE_DIR, in the config_parse_load_modules function. This
way I can inject my module path during runtime. But this only works for the
master process, not the config process which seems to reset its environment
(I assume it does this when dropping privileges). So I did another hack which
lets me pass an argument to the config process which contains the module
path. I can then set this argument in dovecot.conf by service config {
executable = config /my/module/path }.
You can preserve environments by adding them to import_environment setting.
These hacks work, and I can now use both the sieve mail plugin and the sieve
service. I have attached the patch, but this is not a request to add it to
the source. My hack is a hack because I don't know enough about the inner
workings of dovecot to solve it in a good way. Rather, I'm asking for some
way to configure the module path in dovecot, either as an argument to the
master process or as a setting in dovecot.conf. A bonus would be the ability
to specify several paths that dovecot would search, then I can do away with
my virtual module package.
I'd rather make those plugin dirs configurable, since it only adds new settings
that just about nobody changes (and perhaps I shouldn't have added
mail_plugin_dir setting either in the first place).
Re: [Dovecot] Replication -- multiple users, three or more servers?
Replying to Timo: Everything is the same as in that wiki page, except you need to have userdb field override the mail_replica setting. Or I guess you wouldn't want to have a default mail_replica at all, so users won't accidentally get replicated to wrong place. See http://wiki2.dovecot.org/UserDatabase/ExtraFields OK, thanks. Is there a debugging option I can specify here to cause Dovecot to generate more verbose logging output, so I can see exactly what is happening (and what is not working) when I try to run replication? In the Replication wiki page, you show one example using the string remote: at the start of the mail_replica value, and another example starting with remoteprefix:. What is the difference between these? Or is there a typo here? I tried searching the wiki but couldn't find anything explaining this. The example with a dsync wrapper script seems to be describing a situation where the first line of text sent to the remote host consists of the user name (which is read by the wrapper script and passed as a command-line argument to dsync-server). Is this what remoteprefix: does, in contrast to remote:? In the dsync wrapper script example, is vmail in the mail_replica value an example of a user ID to be used on the remote host? What user ID is used on the local host? I think one reason why my tests so far haven't been working may be that I'm not sure which user ID is being used on each end, so my SSH keys aren't being used properly and the connection is failing. Finally, the Replication wiki page mentions the authorized_keys2 file, which (AFAIK) is deprecated in the current SSH -- all authorized keys should be in a single authorized_keys file on the target host, right? Rich Wales ri...@richw.org
Re: [Dovecot] Feature request: Configure CONFIG_MODULE_DIR and AUTH_MODULE_DIR at runtime
Den 2013-04-23 17:20:02 skrev Timo Sirainen t...@iki.fi:
On 23.4.2013, at 17.58, Rickard Nilsson rickard.nils...@telia.com
wrote:
The problem is the service and auth modules, that dovecot tries to load
from the compile-time set MODULE_DIR/{settings,auth}. This is a problem
for me, because I can't set the module path during compilation since
that introduces a circular dependency between the dovecot package and
the virtual dovecot-plugins package.
Sounds like a rather generic problem in nixos. Maybe there could be
generic way to handle this for other packages too, like maybe creating a
whole new directory somewhere (e.g. under /var) that has symlinks to all
the installed plugins?
Yes, that is possible. I can create the plugin directory as part of the
dovecot service startup, I do not need to build it as a separate package.
Could dovecot maybe be made to search for plugins somewhere under
base_dir? I already make sure the base_dir is created before starting the
service, I could assemble a base_dir/plugins or something, too.
I have solved this by hacking dovecot to read an environment variable,
DOVECOT_CONFIG_MODULE_DIR, in the config_parse_load_modules function.
This way I can inject my module path during runtime. But this only
works for the master process, not the config process which seems to
reset its environment (I assume it does this when dropping privileges).
So I did another hack which lets me pass an argument to the config
process which contains the module path. I can then set this argument in
dovecot.conf by service config { executable = config /my/module/path
}.
You can preserve environments by adding them to import_environment
setting.
OK, that's good to know, although I would like to avoid the environment
trickery entirely.
These hacks work, and I can now use both the sieve mail plugin and the
sieve service. I have attached the patch, but this is not a request to
add it to the source. My hack is a hack because I don't know enough
about the inner workings of dovecot to solve it in a good way. Rather,
I'm asking for some way to configure the module path in dovecot, either
as an argument to the master process or as a setting in dovecot.conf. A
bonus would be the ability to specify several paths that dovecot would
search, then I can do away with my virtual module package.
I'd rather make those plugin dirs configurable, since it only adds new
settings that just about nobody changes (and perhaps I shouldn't have
added mail_plugin_dir setting either in the first place).
With configurable, you mean compile-time configurable? I could live with
that. The best would be if the configured paths were relative the
base_dir, as mentioned above. But absolute paths could work too (but it
would make it harder to run several instances side-by-side).
/ Rickard
Re: [Dovecot] Feature request: Configure CONFIG_MODULE_DIR and AUTH_MODULE_DIR at runtime
If you start/stop dovecot with an initscript or some other related system, you can do what SuSE does, since this problem occurs in lots of situations, not just dovecot. Since you know where all the config files are, you could either have the initscript set up a directory with symlinks, as Timo said, or you could collect them together and place them all in one file that is in the correct location. Multiple config files for dovecot can be concatenated together if you are careful to scan for and accommodate include directives. Dem
[Dovecot] mailbox_list_index_parse_header crash
Hi,
I got all excited about IMAP NOTIFY support and tried enabling
mailbox_list_index on my server. Unfortunately, I rather quickly ran
into trouble of the segfault variety. This prevented me from doing
basic things like seeing the contents of some of my folders. Disabling
mailbox_list_index got me back up and running, but... darnit, that's
annoying. The only message I got in my log file was this:
imap(user@domain): Fatal: master: service(imap): child 6899 killed with signal
11 (core dumped)
If I can help track this down, please let me know. Here's the
backtrace:
#0 hash_table_insert_node (table=0x10eff60, key=0x103, value=0x10fd8b0,
check_existing=value optimized out) at hash.c:268
node = 0x69616d2d746e6573
prev = 0x10fbee0
hash = value optimized out
__FUNCTION__ = hash_table_insert_node
#1 0x7fad738a11be in hash_table_insert (table=0x10eff60, key=0x1,
value=0x101) at hash.c:285
node = 0x0
#2 0x7fad73b81e68 in mailbox_list_index_parse_header (list=value optimized
out, view=0x11095f0,
force=value optimized out) at mailbox-list-index.c:196
data = 0x10f5f30
i = 4980
len = 1
size = 8192
id = 1
#3 mailbox_list_index_parse (list=value optimized out, view=0x11095f0,
force=value optimized out)
at mailbox-list-index.c:317
ilist = 0x10edc80
hdr = value optimized out
error = 0x10f5820 `▒\016\001
__FUNCTION__ = mailbox_list_index_parse
#4 0x7fad73b86b03 in mailbox_list_index_sync_begin (list=0x10ed890,
sync_ctx_r=0x7fff2ad61ee0)
at mailbox-list-index-sync.c:247
ilist = 0x10edc80
sync_ctx = value optimized out
index_sync_ctx = value optimized out
view = 0x11095f0
trans = value optimized out
hdr = value optimized out
#5 0x7fad73b86ffb in mailbox_list_index_sync (list=0x10eff60) at
mailbox-list-index-sync.c:382
sync_ctx = 0x1107300
ret = value optimized out
#6 0x7fad73b8233f in mailbox_list_index_refresh (list=0x10ed890) at
mailbox-list-index.c:376
ilist = 0x10edc80
view = 0x1107300
ret = value optimized out
#7 0x7fad73b85e19 in index_list_update_mailbox (box=0x10f40a0) at
mailbox-list-index-status.c:363
list_sync_ctx = 0x1107140
list_view = value optimized out
list_trans = value optimized out
changes = {status = {messages = 718675880, recent = 32767, unseen =
4294967295, uidvalidity = 0, uidnext = 68,
first_unseen_seq = 0, first_recent_uid = 1, last_cached_seq = 0,
highest_modseq = 3176264,
highest_pvt_modseq = 17854784, keywords = 0x10f40a0,
permanent_flags = 17778368, permanent_keywords = 0,
allow_new_keywords = 0, nonpermanent_modseqs = 0, have_guids = 0},
guid = p ▒*▒\177\000\000D\000\000\000\000\000\000, seq = 17750944,
rec_changed = false, msgs_changed = false,
hmodseq_changed = false}
__FUNCTION__ = index_list_update_mailbox
#8 0x7fad73b86089 in index_list_sync_deinit (ctx=0x1107140,
status_r=0x7fff2ad62070) at mailbox-list-index-status.c:470
box = 0x10f40a0
#9 0x7fad73b70f4a in mailbox_sync_deinit (_ctx=0x0, status_r=0x1) at
mail-storage.c:1655
ctx = 0x10eff60
box = 0x10f40a0
errormsg = value optimized out
error = value optimized out
ret = value optimized out
#10 0x7fad73b7100b in mailbox_sync (box=value optimized out, flags=value
optimized out) at mail-storage.c:1681
ctx = 0x0
status = {sync_delayed_expunges = 0}
#11 0x7fad73b9af72 in index_storage_get_status (box=0x10f40a0, items=17,
status_r=value optimized out)
at index-status.c:39
No locals.
#12 0x7fad72cabde4 in fts_mailbox_get_status (box=0x10f40a0, items=17,
status_r=0x7fff2ad621b0) at fts-storage.c:86
seq = value optimized out
#13 0x7fad73b864e6 in index_list_get_status (box=0x10f40a0, items=17,
status_r=0x7fff2ad621b0)
at mailbox-list-index-status.c:162
No locals.
#14 0x0041c8da in imap_status_get (cmd=0x10f1880, ns=0x10e8b00, mailbox=0x10cc2c8
Flight.RV, items=0x7fff2ad62240,
result_r=0x7fff2ad621b0) at imap-status.c:84
client = 0x10f0ce0
box = 0x10f40a0
errstr = value optimized out
ret = value optimized out
#15 0x0041219d in cmd_status (cmd=0x10f1880) at cmd-status.c:40
client = 0x10f0ce0
args = 0x10d7a38
list_args = 0x10d7be0
items = {status = 17, metadata = 0}
result = {status = {messages = 0, recent = 0, unseen = 0, uidvalidity =
0, uidnext = 0, first_unseen_seq = 0,
first_recent_uid = 0, last_cached_seq = 0, highest_modseq = 0,
highest_pvt_modseq = 0, keywords = 0x0,
permanent_flags = 0, permanent_keywords = 0, allow_new_keywords =
0, nonpermanent_modseqs = 0, have_guids = 1},
metadata = {guid = PY\r\001, '\000' repeats 11 times,
virtual_size =
Re: [Dovecot] mailbox_list_index_parse_header crash
Sorry, I should have said; I'm running 2.2.1
On Tuesday, April 23 at 10:52 AM, quoth Kyle Wheeler:
Hi,
I got all excited about IMAP NOTIFY support and tried enabling
mailbox_list_index on my server. Unfortunately, I rather quickly ran
into trouble of the segfault variety. This prevented me from doing
basic things like seeing the contents of some of my folders. Disabling
mailbox_list_index got me back up and running, but... darnit, that's
annoying. The only message I got in my log file was this:
imap(user@domain): Fatal: master: service(imap): child 6899 killed with signal
11 (core dumped)
If I can help track this down, please let me know. Here's the
backtrace:
#0 hash_table_insert_node (table=0x10eff60, key=0x103, value=0x10fd8b0,
check_existing=value optimized out) at hash.c:268
node = 0x69616d2d746e6573
prev = 0x10fbee0
hash = value optimized out
__FUNCTION__ = hash_table_insert_node
#1 0x7fad738a11be in hash_table_insert (table=0x10eff60, key=0x1,
value=0x101) at hash.c:285
node = 0x0
#2 0x7fad73b81e68 in mailbox_list_index_parse_header (list=value optimized
out, view=0x11095f0,
force=value optimized out) at mailbox-list-index.c:196
data = 0x10f5f30
i = 4980
len = 1
size = 8192
id = 1
#3 mailbox_list_index_parse (list=value optimized out, view=0x11095f0,
force=value optimized out)
at mailbox-list-index.c:317
ilist = 0x10edc80
hdr = value optimized out
error = 0x10f5820 `▒\016\001
__FUNCTION__ = mailbox_list_index_parse
#4 0x7fad73b86b03 in mailbox_list_index_sync_begin (list=0x10ed890,
sync_ctx_r=0x7fff2ad61ee0)
at mailbox-list-index-sync.c:247
ilist = 0x10edc80
sync_ctx = value optimized out
index_sync_ctx = value optimized out
view = 0x11095f0
trans = value optimized out
hdr = value optimized out
#5 0x7fad73b86ffb in mailbox_list_index_sync (list=0x10eff60) at
mailbox-list-index-sync.c:382
sync_ctx = 0x1107300
ret = value optimized out
#6 0x7fad73b8233f in mailbox_list_index_refresh (list=0x10ed890) at
mailbox-list-index.c:376
ilist = 0x10edc80
view = 0x1107300
ret = value optimized out
#7 0x7fad73b85e19 in index_list_update_mailbox (box=0x10f40a0) at
mailbox-list-index-status.c:363
list_sync_ctx = 0x1107140
list_view = value optimized out
list_trans = value optimized out
changes = {status = {messages = 718675880, recent = 32767, unseen =
4294967295, uidvalidity = 0, uidnext = 68,
first_unseen_seq = 0, first_recent_uid = 1, last_cached_seq = 0,
highest_modseq = 3176264,
highest_pvt_modseq = 17854784, keywords = 0x10f40a0, permanent_flags
= 17778368, permanent_keywords = 0,
allow_new_keywords = 0, nonpermanent_modseqs = 0, have_guids = 0},
guid = p ▒*▒\177\000\000D\000\000\000\000\000\000, seq = 17750944,
rec_changed = false, msgs_changed = false,
hmodseq_changed = false}
__FUNCTION__ = index_list_update_mailbox
#8 0x7fad73b86089 in index_list_sync_deinit (ctx=0x1107140,
status_r=0x7fff2ad62070) at mailbox-list-index-status.c:470
box = 0x10f40a0
#9 0x7fad73b70f4a in mailbox_sync_deinit (_ctx=0x0, status_r=0x1) at
mail-storage.c:1655
ctx = 0x10eff60
box = 0x10f40a0
errormsg = value optimized out
error = value optimized out
ret = value optimized out
#10 0x7fad73b7100b in mailbox_sync (box=value optimized out, flags=value
optimized out) at mail-storage.c:1681
ctx = 0x0
status = {sync_delayed_expunges = 0}
#11 0x7fad73b9af72 in index_storage_get_status (box=0x10f40a0, items=17,
status_r=value optimized out)
at index-status.c:39
No locals.
#12 0x7fad72cabde4 in fts_mailbox_get_status (box=0x10f40a0, items=17,
status_r=0x7fff2ad621b0) at fts-storage.c:86
seq = value optimized out
#13 0x7fad73b864e6 in index_list_get_status (box=0x10f40a0, items=17,
status_r=0x7fff2ad621b0)
at mailbox-list-index-status.c:162
No locals.
#14 0x0041c8da in imap_status_get (cmd=0x10f1880, ns=0x10e8b00, mailbox=0x10cc2c8
Flight.RV, items=0x7fff2ad62240,
result_r=0x7fff2ad621b0) at imap-status.c:84
client = 0x10f0ce0
box = 0x10f40a0
errstr = value optimized out
ret = value optimized out
#15 0x0041219d in cmd_status (cmd=0x10f1880) at cmd-status.c:40
client = 0x10f0ce0
args = 0x10d7a38
list_args = 0x10d7be0
items = {status = 17, metadata = 0}
result = {status = {messages = 0, recent = 0, unseen = 0, uidvalidity =
0, uidnext = 0, first_unseen_seq = 0,
first_recent_uid = 0, last_cached_seq = 0, highest_modseq = 0,
highest_pvt_modseq = 0, keywords = 0x0,
permanent_flags = 0, permanent_keywords = 0, allow_new_keywords = 0,
nonpermanent_modseqs = 0, have_guids = 1},
metadata = {guid = PY\r\001,
Re: [Dovecot] mailbox_list_index_parse_header crash
On Tue, 2013-04-23 at 10:52 -0600, Kyle Wheeler wrote: I got all excited about IMAP NOTIFY support and tried enabling mailbox_list_index on my server. Unfortunately, I rather quickly ran into trouble of the segfault variety. This prevented me from doing basic things like seeing the contents of some of my folders. Disabling mailbox_list_index got me back up and running, but... darnit, that's annoying. The only message I got in my log file was this: imap(user@domain): Fatal: master: service(imap): child 6899 killed with signal 11 (core dumped) If I can help track this down, please let me know. Here's the backtrace: #0 hash_table_insert_node (table=0x10eff60, key=0x103, value=0x10fd8b0, check_existing=value optimized out) at hash.c:268 node = 0x69616d2d746e6573 prev = 0x10fbee0 hash = value optimized out __FUNCTION__ = hash_table_insert_node http://hg.dovecot.org/dovecot-2.2/rev/d3d380221043 should help?
Re: [Dovecot] mailbox_list_index_parse_header crash
On Tuesday, April 23 at 09:06 PM, quoth Timo Sirainen: On Tue, 2013-04-23 at 10:52 -0600, Kyle Wheeler wrote: I got all excited about IMAP NOTIFY support and tried enabling mailbox_list_index on my server. Unfortunately, I rather quickly ran into trouble of the segfault variety. This prevented me from doing basic things like seeing the contents of some of my folders. Disabling mailbox_list_index got me back up and running, but... darnit, that's annoying. The only message I got in my log file was this: imap(user@domain): Fatal: master: service(imap): child 6899 killed with signal 11 (core dumped) If I can help track this down, please let me know. Here's the backtrace: #0 hash_table_insert_node (table=0x10eff60, key=0x103, value=0x10fd8b0, check_existing=value optimized out) at hash.c:268 node = 0x69616d2d746e6573 prev = 0x10fbee0 hash = value optimized out __FUNCTION__ = hash_table_insert_node http://hg.dovecot.org/dovecot-2.2/rev/d3d380221043 should help? Excellent - running tests now... answers soon. ~Kyle -- Human beings are the only creatures that allow their children to come back home. -- Bill Cosby pgpt31sqQeiQL.pgp Description: PGP signature
Re: [Dovecot] Using dsync to export mail to remote IMAP account
Timo Sirainen writes: I've read the web/man pages on dsync, but it's not clear to me whether dsync can be used to export (rather than import) a user's mailbox to a remote non-dovecot IMAP account. It should be possible at some point, but currently probably won't work very well. Ah, thanks for the clarification. dsync(localuser): Error: user localuser: Initialization failed: Namespace '': Unknown mail storage driver imapc dsync(localuser): Fatal: User init failed But this looks like you simply haven't compiled Dovecot with imapc support. See if dovecot --build-options|grep storage returns imapc. Right you are. Joseph Tam jtam.h...@gmail.com
Re: [Dovecot] Make install error
Hi, I tried remove and make install, same err happended. I noticed from the log below, it first generate the /usr/local/dovecot/lib/dovecot/auth with checkpassword-reply, and it is success, the coming generation directory for auth at /usr/local/dovecot/lib/dovecot/, it is weird that the make install generation for file auth and directory auth at same path. It is causing the issues. make[3]: Entering directory `/usr/local/src/dovecot-2.2.1/src/auth' test -z /usr/local/dovecot/lib/dovecot || /usr/bin/mkdir -p /usr/local/dovecot/lib/dovecot /bin/sh ../../libtool --mode=install /usr/bin/install -c auth checkpassword-reply '/usr/local/dovecot/lib/dovecot' libtool: install: /usr/bin/install -c .libs/auth /usr/local/dovecot/lib/dovecot/auth libtool: install: /usr/bin/install -c .libs/checkpassword-reply /usr/local/dovecot/lib/dovecot/checkpassword-reply test -z /usr/local/dovecot/lib/dovecot/auth || /usr/bin/mkdir -p /usr/local/dovecot/lib/dovecot/auth /usr/bin/mkdir: cannot create directory ‘/usr/local/dovecot/lib/dovecot/auth’: File exists make[3]: *** [install-auth_moduleLTLIBRARIES] Error 1 make[3]: Leaving directory `/usr/local/src/dovecot-2.2.1/src/auth' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/usr/local/src/dovecot-2.2.1/src/auth' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/dovecot-2.2.1/src' make: *** [install-recursive] Error 1 On 4/23/13 6:30 PM, Timo Sirainen wrote: On Fri, 2013-04-19 at 11:50 +0800, kengheng wrote: Hi, I'm recompiling dovecot 2.2.0/2.2.1 with error below during make install: test -z /usr/local/dovecot/lib/dovecot/auth || /usr/bin/mkdir -p /usr/local/dovecot/lib/dovecot/auth /usr/bin/mkdir: cannot create directory ‘/usr/local/dovecot/lib/dovecot/auth’: File exists This file shouldn't exist. The target Svr OS: OpenSuse 12.2 x86 and installed success for qmail/vpopmail. The configuration for dovecot as below: ./configure \ --prefix=/usr/local/dovecot \ --with-vpopmail \ --with-docs \ --with-ssl \ --without-shadow \ --without-pam \ --without-ldap \ --without-pgsql \ --without-sql \ --without-mysql \ --without-sqlite I think there's an older differently installed Dovecot in there. rm -rf /usr/local/dovecot/lib and try make install again.
