[Dovecot] Upgrading Dovecot v1.0.10 -> v2.0.9
Hi all, OK, I admit it. I've seriously neglected our Dovecot installation. I installed version 1.0.10 in Jan 2008, and it has been a great workhorse since then. It has run like a champ, so it was ignored due to higher priority projects. But now it is time to get current with Dovecot, and I really need your help. We are using the mbox mailbox format. First so I want to upgrade to 2.0.9, since it looks like that is the latest version? It looks like development is still happening on the 1.x line, so do I need to get to the 2.x line? Any comments/suggestions/recommendations on that? I know there are major changes from 1.x -> 2.x.. Also, do I need to go through incremental upgrades? I'm guessing changes have been made to the index files and the dovecot configuration. Do those need to be done in steps, or can I made a major leap forward? I'd appreciate any input on this project. I need to start planning. Thanks so much! Jackie
Re: [Dovecot] Problem Compiling 1.1.1 on AIX
> Can you somehow enable C99 support for xlc? Is there something like a > -c99 parameter? Thank Timo, Woosan and Asheesh for your help. I did see a parameter for xlc (-qlanglvl=extc99), but our compiler is too old, and it doesn't recognize it. I then tried gcc, we had version 4.0.0 installed, and it does compile. I did have to do the changes Woonsan recommended (below). > In my case, I succeeded in making it after modification of two > generated sources: > > (1) src/plugins/quota/rquota.h > I added `#include ' on the top. > (2) src/plugins/quota/rquota_xdr.c > I modified it like the following: > #include "/usr/include/rpcsvc/rquota.h" > ==> > #include "rquota.h" My compiliation method wasn't very elegant. I did the make, saw an error, and rquota.h was created. I edited rquota.h as shown above. I ran make a second time which errored, but generated rquota_xdr.c. I edited rquota_xdr.c, and the third make succeeded. Is there a cleaner method to use? Thanks again, it's very comforting to know I can compile it! Jackie --- Jackie Hunt ACNS Colorado State University Fort Collins, CO 80523
Re: [Dovecot] Problem Compiling 1.1.1 on AIX
> > Hi Jackie, > > I compiled dovecot-1.1.1 on AIX 5.3 with xlc, "IBM(R) XL C/C++ Enterprise > Edition V8.0 for AIX(R)", but I didn't see that error. Which version of > xlc are you using? Thanks for the feedback, Woonsan. Good to know it works for you. We do have a very old copy of the compiler: C for AIX Compiler Version 5.0.1.0 I'm sure that is my issue. I think it is a "variadic macro extension" feature that isn't supported by our version. > > In my case, I succeeded in making it after modification of two generated > sources: > > (1) src/plugins/quota/rquota.h > I added `#include ' on the top. > (2) src/plugins/quota/rquota_xdr.c > I modified it like the following: > #include "/usr/include/rpcsvc/rquota.h" > ==> > #include "rquota.h" Thanks for this as well. I may need it, once I get my compiler issue fixed! Jackie --- Jackie Hunt ACNS Colorado State University Fort Collins, CO 80523
[Dovecot] Problem Compiling 1.1.1 on AIX
Hi all,
We've been running Dovecot since December '07 with with no glitches.
It's a great solid piece of software, thanks so much Timo!!
I thought I'd try out 1.1.1, so I brought it down and tried compiling
it on AIX, using the IBM compiler, xlc. It's what I've used all along.
The error I'm seeing on the make is:
source='array.c' object='array.o' libtool=no DEPDIR=.deps depmode=aix /
bin/sh ../../depcomp xlc -DHAVE_CONFIG_H -I. -I../..-I/usr/local/openssl_0.
9.7e/include -g -qcpluscmt -c array.c
"macros.h", line 149.68: 1506-211 (S) Parameter list must be empty, or consist o
f one or more identifiers separated by commas.
make: 1254-004 The error code from the last command is 1.
Looking at macros.h, the section it is erroring on is:
#ifdef CONTEXT_TYPE_SAFETY
# define CONTEXT_CALLBACK(name, callback_type, callback, context, ...) \
({(void)(1 ? 0 : callback(context)); \
name(__VA_ARGS__, (callback_type *)callback, context); })
#else
# define CONTEXT_CALLBACK(name, callback_type, callback, context, ...) \
name(__VA_ARGS__, (callback_type *)callback, context)
#endif
The second define is the line the error occurs on. Has anyone seen this
before. I'm assuming xlc can't handle the '...' parameter, and an hoping
there is an option I can enable. Just thought I might see if anyone else
has already solved this issue.
Thanks much!
Jackie
Jackie Hunt
ACNS
Colorado State University
Fort Collins, CO 80523
[Dovecot] "Connection queue full" errors
Hi all, Our Dovecot server became non-responsive today and had to be restarted. We had approximately 1200 imap sessions running, and when I looked at the log, I found the following errors: Jan 16 10:02:01 lamar dovecot: imap-login: Disconnected: Connection queue full: rip=75.166.40.150, lip=129.82.103.75, TLS handshake Jan 16 10:02:01 lamar dovecot: imap-login: Disconnected: Connection queue full: rip=75.166.40.150, lip=129.82.103.75, TLS handshake Jan 16 10:02:12 lamar dovecot: imap-login: Disconnected: Connection queue full: rip=75.166.40.150, lip=129.82.103.75, TLS handshake Jan 16 10:02:26 lamar dovecot: imap-login: Disconnected: Connection queue full: rip=67.162.151.85, lip=129.82.103.75, TLS handshake Jan 16 10:02:26 lamar dovecot: imap-login: Disconnected: Connection queue full: rip=129.82.100.135, lip=129.82.103.75 Jan 16 10:02:26 lamar dovecot: imap-login: Disconnected: Connection queue full: rip=71.196.217.203, lip=129.82.103.75 Jan 16 10:02:26 lamar dovecot: imap-login: Disconnected: Connection queue full: rip=129.82.100.135, lip=129.82.103.75 Jan 16 10:02:26 lamar dovecot: imap-login: Disconnected: Connection queue full: rip=129.82.100.135, lip=129.82.103.75 Jan 16 10:02:26 lamar dovecot: imap-login: Disconnected: Connection queue full: rip=129.82.218.58, lip=129.82.103.75 ... We are running v1.0.10 on AIX. Here's the relevant configuration from dovecot.conf: # Set max. process size in megabytes. #login_process_size = 32 # Should each login be processed in it's own process (yes), or should one # login process be allowed to process multiple connections (no)? login_process_per_connection = no # Number of login processes to keep for listening new connections. #login_processes_count = 3 # Maximum number of login processes to create. #login_max_processes_count = 128 # Maximum number of connections allowed per each login process. #login_max_connections = 256 We are running in the high-performance mode, where each login process can handle a number of connections. As I understand it that means we have login_max_connections * login_max_processes_count available possible logins at a given time. That's 32K with our configuration. That seems like a very high limit. Is that what these errors are indicating? Thanks for any insight on this, Jackie --- Jackie Hunt ACNSVoice: (970) 663-3789 Colorado State University FAX:(970) 491-1958 Fort Collins, CO 80523 Email: [EMAIL PROTECTED]
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
> Problem was that it was reading a 50MB mail in 12kB blocks, and Dovecot > wasn't handling that very well. Fixed: > > http://hg.dovecot.org/dovecot-1.0/rev/0fba164c6ba6 > http://hg.dovecot.org/dovecot-1.0/rev/edd95f9c6ba4 That's awesome! Thanks so much Timo, you always come through! I'll install the fixes ASAP. Jackie --- Jackie Hunt ACNSVoice: (970) 663-3789 Colorado State University FAX:(970) 491-1958 Fort Collins, CO 80523 Email: [EMAIL PROTECTED]
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
> Thanks for the suggestion on the truss command, Timo: > > "truss -d -rO -w1" We have seen the imap process consuming 100% CPU again, and this time I was able to get a trace, but it's too long to post to the list. I've sent a copy to Timo. Let me know if anyone else would like a copy of it. This user is running Thunderbird on Solaris, and has at least two IMAP connections open continuously, one to a UofW server running on Solaris (I think), the other to Dovecot running on AIX. He has problems with the Dovecot connection hanging on him each morning. Thunderbird shows an hourglass, but he gets not indication of what is happening. He has to shut down Thunderbird to get it working again. It's a bit ironic/humorous, but his UofW connection is fine in Thunderbird, and that's how he notifies me his Dovecot imap is hung up. We are running Dovecot 1.0.5 on AIX. Thanks for any help! Jackie --- Jackie Hunt ACNSVoice: (970) 663-3789 Colorado State University FAX:(970) 491-1958
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
>:w On Mon, 2007-11-19 at 16:12 -0500, Stewart Dean wrote: > > I think I'm seeing this with TBird and 1.0.7...with my own account! It > > may even be a Tbird problem. > > I have a 4way mail server, so when I get 25%, it's 100% of one > > processor. I tried killing the imap process on the server and it can > > back at 9% and climbed quickly back up to 25%. It wasn't until I > > shutdown my TBird session that a clean imap session was established. > > You could truss the process or do something else to find out what > Thunderbird and Dovecot are talking to each others. If shutting down > Thunderbird dropped the load, it sounds like a bug in Thunderbird. Some > clients have been known to keep requesting same data over and over again > from the server in some situations. If I could see what the IMAP traffic > looks like, I might be able to add a workaround to it. > What Stewart describes sounds exactly like what we are seeing. Killing the imap process doesn't change anything, it requires the client to be shut down to avoid using 100% CPU. We have a user who was seeing this every morning. However, something has changed and he now sees it about every 7 to 10 days. Another interesting note is that he didn't see the issue when we were running U of Wash's imap server. Thanks for the suggestion on the truss command, Timo: "truss -d -rO -w1" I'll definitely post my results when I have some. Jackie --- Jackie Hunt ACNSVoice: (970) 663-3789 Colorado State University FAX:(970) 491-1958 Fort Collins, CO 80523 Email: [EMAIL PROTECTED]
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
>
> Is this behavior cured, or do you continue to see it?
>
No, the behavior isn't cured. We still continue to see it
with various clients. I have posted a couple of truss outputs,
but so far no resolution.
Sorry for the slow response. I've been "fighting other fires".
Jackie
> Jackie Hunt wrote:
> >> On Mon, 2007-09-03 at 12:37 +0200, Robert Tomanek wrote:
> >>
> >>> Hi,
> >>>
> >>> Sunday, September 2, 2007, 22:42:37, you wrote:
> >>>
> >>>>> 0x0806049d in imap_sync_more (ctx=3D0x80d9770) at imap-sync.c:104
> >>>>> 104 if (ctx->seq =3D=3D 0) {
> >>>>>
> >>> A short follow-up on this, looks like an infinite loop to me, unless
> >>> some threading magic is supposed to happen here:
> >>>
> >> Fixed: http://hg.dovecot.org/dovecot-1.0/rev/8e86137a04fb
> >>
> >
> > We also are seeing imap processes consuming 100% CPU. We have
> > installed Dovecot v1.0.5 and still see the problem. I have a user
> > who can pretty reliably reproduce the problem. It occurs each
> > morning after the imap connection has been idling all night. The
> > user is running Thunderbird 2.0.0.6 (I think) on Solaris. On the
> > client side, he see an hourglass that never goes away, has to shut
> > down Thunderbird.
> >
> > Below is a log, which shows how the CPU is being used (the ps commands
> > are done one right after another) and a dbx trace of the state of
> > the imap process. I'm hoping that's enough info to figure out what's
> > happening.
> >
> > Thanks much,
> > Jackie
> > ---
> > Jackie Hunt
> > ACNSVoice: (970) 663-3789
> > Colorado State University FAX:(970) 491-1958
> > Fort Collins, CO 80523 Email: [EMAIL PROTECTED]
> >
> >
> > $ ps -ef | grep -i xx | grep imap
> > xx 43004 92942 74 07:15:33 - 38:54 imap
> > $ ps -ef | grep -i xx | grep imap
> > xx 43004 92942 81 07:15:33 - 38:58 imap
> > $ ps -ef | grep -i xx | grep imap
> > xx 43004 92942 120 07:15:33 - 39:01 imap
> > $ dbx -a 43004
> > Waiting to attach to process 43004 ...
> > Successfully attached to imap.
> > warning: Directory containing imap could not be determined.
> > Apply 'use' command to initialize source path.
> >
> > Type 'help' for help.
> > reading symbolic information ...
> > stopped in pread at 0xd01f06cc
> > 0xd01f06cc (pread+0x30) 80410014lwz r2,0x14(r1)
> > (dbx) step
> > stopped in istream-file._read at line 120 in file ""
> > could not read "istream-file.c"
> > (dbx) use src lib src/lib src/lib-storage/index/mbox src/lib-mail
> > src/lib-storage/index src/lib-storage src/imap src/imap-login
> > (dbx) use
> > src lib src/lib src/lib-storage/index/mbox src/lib-mail
> > src/lib-storage/index src/lib-storage src/imap src/imap-login
> > (dbx) where
> > istream-file._read(stream = 0x200274a8), line 120 in "istream-file.c"
> > i_stream_read(stream = 0x200274cc), line 58 in "istream.c"
> > istream-raw-mbox._read(stream = 0x20028ab8), line 160 in
> > "istream-raw-mbox.c"
> > i_stream_read(stream = 0x20028adc), line 58 in "istream.c"
> > istream-limit._read(stream = 0x20031458), line 56 in "istream-limit.c"
> > i_stream_read(stream = 0x2003147c), line 58 in "istream.c"
> > istream-header-filter._read(stream = 0x2004aa98), line 234 in
> > "istream-header-filter.c"
> > i_stream_read(stream = 0x2004aabc), line 58 in "istream.c"
> > i_stream_read_data(stream = 0x2004aabc, data = 0x2ff22630, size =
> > 0x2ff22638, threshold = 1), line 250 in "istream.c"
> > message_get_body_size(input = 0x2004aabc, body = 0x2002827c, has_nuls =
> > (nil)), line 107 in "message-size.c"
> > index_mail_init_stream(_mail = 0x200281a8, hdr_size = 0x2ff227a8, body_size
> > = 0x2ff227b8), line 502 in "index-mail.c"
> > mbox_mail_get_stream(_mail = 0x200281a8, hdr_size = 0x2ff227a8, body_size =
> > 0x2ff227b8), line 206 in "mbox-mail.c"
> > mail_get_stream(mail = 0x200281a8, hdr_size = 0x2ff227a8, body_size =
> > 0x2ff227b8), line 107 in "mail.c"
> > imap-fetch-body.fetch_body(ctx = 0x200205e0, mail = 0x200281
[Dovecot] Disconnects in log
Hi all, I need some help interpreting the info I'm seeing in the dovecot logs. I have a user using Outlook who is having connectively problems. Below is a sample of what the Dovecot log is showing. Can anyone explain to me why multiple logins occur within a few seconds of each other? Also, as I understand it, the "Disconnected" messages mean the kernel told Dovecot the connection was closed. I'm trying to figure out why I'm seeing so many of these. And why they seem to occur shortly after a login. Thanks for any insight! Jackie -- Jackie Hunt ACNSVoice: (970) 663-3789 Colorado State University FAX:(970) 491-1958 Fort Collins, CO 80523 Email: [EMAIL PROTECTED] Oct 10 09:05:26 lamar dovecot: imap-login: Login: user=, method=PLAIN, ri p=129.82.xxx.yy, lip=129.82.rrr.ss, TLS Oct 10 09:05:27 lamar dovecot: imap-login: Login: user=, method=PLAIN, ri p=129.82.xxx.yy, lip=129.82.rrr.ss, TLS Oct 10 09:05:36 lamar dovecot: imap-login: Login: user=, method=PLAIN, ri p=129.82.xxx.yy, lip=129.82.rrr.ss, TLS Oct 10 09:06:28 lamar dovecot: IMAP(auser): Disconnected Oct 10 09:06:28 lamar dovecot: IMAP(auser): Disconnected Oct 10 09:35:28 lamar dovecot: imap-login: Login: user=, method=PLAIN, ri p=129.82.xxx.yy, lip=129.82.rrr.ss, TLS Oct 10 09:35:28 lamar dovecot: imap-login: Login: user=, method=PLAIN, ri p=129.82.xxx.yy, lip=129.82.rrr.ss, TLS Oct 10 09:36:11 lamar dovecot: IMAP(auser): Disconnected: Logged out Oct 10 10:01:25 lamar dovecot: IMAP(auser): Disconnected Oct 10 10:05:28 lamar dovecot: imap-login: Login: user=, method=PLAIN, ri p=129.82.xxx.yy, lip=129.82.rrr.ss, TLS Oct 10 10:05:29 lamar dovecot: imap-login: Login: user=, method=PLAIN, ri p=129.82.xxx.yy, lip=129.82.rrr.ss, TLS Oct 10 10:06:16 lamar dovecot: IMAP(auser): Disconnected Oct 10 10:06:16 lamar dovecot: IMAP(auser): Disconnected Oct 10 10:12:32 lamar dovecot: imap-login: Login: user=, method=PLAIN, ri p=129.82.xxx.yy, lip=129.82.rrr.ss, TLS Oct 10 10:24:23 lamar dovecot: IMAP(auser): Disconnected Oct 10 10:24:50 lamar dovecot: imap-login: Login: user=, method=PLAIN, ri p=129.82.xxx.yy, lip=129.82.rrr.ss, TLS Oct 10 10:35:29 lamar dovecot: imap-login: Login: user=, method=PLAIN, ri p=129.82.xxx.yy, lip=129.82.rrr.ss, TLS Oct 10 10:35:29 lamar dovecot: imap-login: Login: user=, method=PLAIN, ri p=129.82.xxx.yy, lip=129.82.rrr.ss, TLS Oct 10 10:36:18 lamar dovecot: IMAP(auser): Disconnected Oct 10 10:36:18 lamar dovecot: IMAP(auser): Disconnected: Logged out
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
Attached is the truss for the imap process we are seeing which is chewing up CPU. We've seen this issue on several different clients, usually first thing in the morning. Shutting down the client and restarting always seems to get Dovecot back in sync. Hope we can get some help with this. We're running 1.0.5. Thanks! Jackie Hunt ACNSVoice: (970) 663-3789 Colorado State University FAX:(970) 491-1958 Fort Collins, CO 80523 Email: [EMAIL PROTECTED] On Sun, 30 Sep 2007, Timo Sirainen wrote: > On Wed, 2007-09-26 at 09:12 -0600, Jackie Hunt wrote: > > istream-file._read(stream = 0x200274a8), line 120 in "istream-file.c" > > i_stream_read(stream = 0x200274cc), line 58 in "istream.c" > > istream-raw-mbox._read(stream = 0x20028ab8), line 160 in > > "istream-raw-mbox.c" > > i_stream_read(stream = 0x20028adc), line 58 in "istream.c" > > istream-limit._read(stream = 0x20031458), line 56 in "istream-limit.c" > > i_stream_read(stream = 0x2003147c), line 58 in "istream.c" > > istream-header-filter._read(stream = 0x2004aa98), line 234 in > > "istream-header-filter.c" > > i_stream_read(stream = 0x2004aabc), line 58 in "istream.c" > > i_stream_read_data(stream = 0x2004aabc, data = 0x2ff22630, size = > > 0x2ff22638, threshold = 1), line 250 in "istream.c" > > message_get_body_size(input = 0x2004aabc, body = 0x2002827c, has_nuls = > > (nil)), line 107 in "message-size.c" > > index_mail_init_stream(_mail = 0x200281a8, hdr_size = 0x2ff227a8, body_size > > = 0x2ff227b8), line 502 in "index-mail.c" > > mbox_mail_get_stream(_mail = 0x200281a8, hdr_size = 0x2ff227a8, body_size = > > 0x2ff227b8), line 206 in "mbox-mail.c" > > mail_get_stream(mail = 0x200281a8, hdr_size = 0x2ff227a8, body_size = > > 0x2ff227b8), line 107 in "mail.c" > > imap-fetch-body.fetch_body(ctx = 0x200205e0, mail = 0x200281a8, context = > > 0x20020858), line 331 in "imap-fetch-body.c" > > imap_fetch(ctx = 0x200205e0), line 291 in "imap-fetch.c" > > cmd_fetch(cmd = 0x2001e35c), line 163 in "cmd-fetch.c" > > cmd_uid(cmd = 0x2001e35c), line 19 in "cmd-uid.c" > > client_handle_input(cmd = 0x2001e35c), line 344 in "client.c" > > client_handle_input(cmd = 0x2001e35c), line 398 in "client.c" > > _client_input(context = 0x2001e318), line 441 in "client.c" > > io_loop_handler_run(ioloop = 0x2001d0e8), line 199 in "ioloop-poll.c" > > io_loop_run(ioloop = 0x2001d0e8), line 329 in "ioloop.c" > > This looks like a normal UID FETCH command. Are you sure Dovecot is > doing infinite looping here, or if it's just that Thunderbird is sending > the same UID FETCH command over and over? > > If it's Dovecot doing the infinite loop, could you truss the process for > a while and show me the output? > > Or it would be good to know which one of these functions is looping. Can > you set breakpoints and continue the execution? With gdb I'd do: > > b imap_fetch > continue > // does it stop? if not, ^C and try the next one: > b fetch_body > continue > b mail_get_stream > continue > ..etc.. > > The last breakpoint where it doesn't stop is looping. > truss.log.gz Description: Binary data
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
> On Mon, 2007-09-03 at 12:37 +0200, Robert Tomanek wrote:
> > Hi,
> >
> > Sunday, September 2, 2007, 22:42:37, you wrote:
> > >> 0x0806049d in imap_sync_more (ctx=3D0x80d9770) at imap-sync.c:104
> > >> 104 if (ctx->seq =3D=3D 0) {
> >
> > A short follow-up on this, looks like an infinite loop to me, unless
> > some threading magic is supposed to happen here:
>
> Fixed: http://hg.dovecot.org/dovecot-1.0/rev/8e86137a04fb
We also are seeing imap processes consuming 100% CPU. We have
installed Dovecot v1.0.5 and still see the problem. I have a user
who can pretty reliably reproduce the problem. It occurs each
morning after the imap connection has been idling all night. The
user is running Thunderbird 2.0.0.6 (I think) on Solaris. On the
client side, he see an hourglass that never goes away, has to shut
down Thunderbird.
Below is a log, which shows how the CPU is being used (the ps commands
are done one right after another) and a dbx trace of the state of
the imap process. I'm hoping that's enough info to figure out what's
happening.
Thanks much,
Jackie
---
Jackie Hunt
ACNSVoice: (970) 663-3789
Colorado State University FAX:(970) 491-1958
Fort Collins, CO 80523 Email: [EMAIL PROTECTED]
$ ps -ef | grep -i xx | grep imap
xx 43004 92942 74 07:15:33 - 38:54 imap
$ ps -ef | grep -i xx | grep imap
xx 43004 92942 81 07:15:33 - 38:58 imap
$ ps -ef | grep -i xx | grep imap
xx 43004 92942 120 07:15:33 - 39:01 imap
$ dbx -a 43004
Waiting to attach to process 43004 ...
Successfully attached to imap.
warning: Directory containing imap could not be determined.
Apply 'use' command to initialize source path.
Type 'help' for help.
reading symbolic information ...
stopped in pread at 0xd01f06cc
0xd01f06cc (pread+0x30) 80410014lwz r2,0x14(r1)
(dbx) step
stopped in istream-file._read at line 120 in file ""
could not read "istream-file.c"
(dbx) use src lib src/lib src/lib-storage/index/mbox src/lib-mail
src/lib-storage/index src/lib-storage src/imap src/imap-login
(dbx) use
src lib src/lib src/lib-storage/index/mbox src/lib-mail src/lib-storage/index
src/lib-storage src/imap src/imap-login
(dbx) where
istream-file._read(stream = 0x200274a8), line 120 in "istream-file.c"
i_stream_read(stream = 0x200274cc), line 58 in "istream.c"
istream-raw-mbox._read(stream = 0x20028ab8), line 160 in "istream-raw-mbox.c"
i_stream_read(stream = 0x20028adc), line 58 in "istream.c"
istream-limit._read(stream = 0x20031458), line 56 in "istream-limit.c"
i_stream_read(stream = 0x2003147c), line 58 in "istream.c"
istream-header-filter._read(stream = 0x2004aa98), line 234 in
"istream-header-filter.c"
i_stream_read(stream = 0x2004aabc), line 58 in "istream.c"
i_stream_read_data(stream = 0x2004aabc, data = 0x2ff22630, size = 0x2ff22638,
threshold = 1), line 250 in "istream.c"
message_get_body_size(input = 0x2004aabc, body = 0x2002827c, has_nuls = (nil)),
line 107 in "message-size.c"
index_mail_init_stream(_mail = 0x200281a8, hdr_size = 0x2ff227a8, body_size =
0x2ff227b8), line 502 in "index-mail.c"
mbox_mail_get_stream(_mail = 0x200281a8, hdr_size = 0x2ff227a8, body_size =
0x2ff227b8), line 206 in "mbox-mail.c"
mail_get_stream(mail = 0x200281a8, hdr_size = 0x2ff227a8, body_size =
0x2ff227b8), line 107 in "mail.c"
imap-fetch-body.fetch_body(ctx = 0x200205e0, mail = 0x200281a8, context =
0x20020858), line 331 in "imap-fetch-body.c"
imap_fetch(ctx = 0x200205e0), line 291 in "imap-fetch.c"
cmd_fetch(cmd = 0x2001e35c), line 163 in "cmd-fetch.c"
cmd_uid(cmd = 0x2001e35c), line 19 in "cmd-uid.c"
client_handle_input(cmd = 0x2001e35c), line 344 in "client.c"
client_handle_input(cmd = 0x2001e35c), line 398 in "client.c"
_client_input(context = 0x2001e318), line 441 in "client.c"
io_loop_handler_run(ioloop = 0x2001d0e8), line 199 in "ioloop-poll.c"
io_loop_run(ioloop = 0x2001d0e8), line 329 in "ioloop.c"
main(argc = 1, argv = 0x2ff22b50, envp = 0x2ff22b58), line 290 in "main.c"
(dbx) list
58 return _stream->read(_stream);
59 }
60
61 void i_stream_skip(struct istream *stream, uoff_t count)
62 {
63 struct _istream *_stream = stream->real_stream;
64 size_t data_size;
65
66 data_size = _stream->pos - _stream->skip;
67 if (count <= data_size) {
(dbx) dump
i_stream_read(stream = 0x2003147c), line 58 in "istream.c"
_stream = 0x20031458
(dbx) up
istream-header-f
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
> Start dbx, and type 'attach ' at its prompt. > > -Brian Hayden > OIT Internet Services, > University of Minnesota Thanks, Brian. Got me looking again and on AIX I can use: dbx -a I'll see what I can learn... Jackie --- Jackie Hunt ACNSVoice: (970) 663-3789 Colorado State University FAX:(970) 491-1958 Fort Collins, CO 80523 Email: [EMAIL PROTECTED]
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
> > Hello Jackie, > > Unfortunately, I am not really moving forward with that as I do not > have much insight into the context structure in question. I guess we > need to wait until Timo answers my e-mail. Yes, haven't seen much from him lately. Must be busy or vacation... > On the other hand, nice the hear I am not the only person with this > problem :-| I think I've also seen these posted in the past from users. We hadn't experienced it until recently, just went into "production" this summer. > Jackie, is there a chance you could confirm my doubts by doing what > I did in and the > original message? This way we would be sure we are talking about the > same problem cause here since 'Dovecot hangs' sounds a bit generic. > I think the stack trace and the variable values should be enough to > confirm it. Sorry, don't know about the mid: protocol. Not sure how to get to the reference you sent. From your email it looks like gdb has the ability to attach to a running process. We have dbx which I don't believe can do that. It would be nice to confirm our issues are the same though. What I'd really like is to find a way to recreate the problem. Jackie --- Jackie Hunt ACNSVoice: (970) 663-3789 Colorado State University FAX:(970) 491-1958 Fort Collins, CO 80523 Email: [EMAIL PROTECTED]
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
> > Hi, > > I have yet another problem with Dovecot: sometimes (rarely, maybe > once every few days) one of the imap processes will 'hang', > consuming all available CPU time. It does not seem to 'finish' in any > reasonable amount of time (in one instance I waited a few days). > > Robert Tomanek mailto:[EMAIL PROTECTED] We have also seen this behavior, running Dovecot 1.0 on AIX. Thanks for your debug work on it Robert. Jackie --- Jackie Hunt ACNSVoice: (970) 663-3789 Colorado State University FAX:(970) 491-1958 Fort Collins, CO 80523 Email: [EMAIL PROTECTED]
[Dovecot] Server Timed Out: Outlook Express
Hi all, We just started running Dovecot this fall here on campus v 1.0. I've started getting some trouble reports from users. An Outlook Express users reported seeing the "Server has not responded in 60 seconds" messages. Waiting longer doesn't help, he has to stop/start Outlook Express to get connected again. Also have a Thunderbird user who is seeing that type of behavior first thing in the morning after being logged in all night. He has to stop/restart Thunderbird. Also, have had some reports of "disconnected" showing up on the Outlook2007 status bar. I've looked at the Dovecot log, and don't see any errors. I do see lots of "Disconnected", "Disconnected in IDLE" and "Disconnected: Logged Out". These last two seem normal, if I just see "Disconnected" is that a flag that we're losing connections abnormally? I know version 1.0.3 is out. I've looked at the changes, and the only one I can see that might be related to what we are seeing is the IDLE commmand fix. Was hoping for some advice on whether upgrading might resolve these issue. Any insight would be greatly appreciated. Jackie --- Jackie Hunt ACNSVoice: (970) 663-3789 Colorado State University FAX:(970) 491-1958 Fort Collins, CO 80523 Email: [EMAIL PROTECTED]
[Dovecot] Log Message Disconnected: Disconnected
We just started running Dovecot this summer at our campus. Overall things have gone very well, and performance have improved since moving off of U of Wash. We have run into an issue with a user running Thunderbird 2.0.0.6 on Solaris. He is seeing a very long response time (20mins+) on his first mailbox selection each morning when he comes into work. I looked at the Dovecot log, and the only think I can see that might be a bit out of the ordinary is two Disconnected messages that happen about 30 minutes apart each morning: Aug 17 04:54:08 host dovecot: IMAP(uname): Disconnected: Disconnected Aug 17 05:24:09 host dovecot: IMAP(uname): Disconnected: Disconnected The disconnected messages for other users say "Disconnected: Logged Out". I don't know for sure if these messages are related to his problem. Can anyone can shed some light on why Dovecot might indicate a "double disconnect"? Thanks, Jackie --- Jackie Hunt ACNSVoice: (970) 663-3789 Colorado State University FAX:(970) 491-1958 Fort Collins, CO 80523 Email: [EMAIL PROTECTED]
