Hi,
Just upgraded to 3.1.17.
I will keep you informed if this error happens again.
Sincerely.
Rogerio
---Mensagem Original
Data: Wed 08/10/2014
Remetente: 'Rogerio Pereira'
Para: dbmail@dbmail.org
Assunto: imapd _ libzdb problem
Hi,
I am running Dbmail
Am 08.10.2014 um 23:01 schrieb Rogerio Pereira:
I am running Dbmail 3.1.13, Debian, PostgreSQL 9.3. The database size is
100 GB, for 1,000 users.
Today I received an error as follows:
Oct 08 11:01:05 xxx.dbmail dbmail-imapd[14946]: [0x7f3f1b1ec0a0]
Alert:[libzdb] TabortHandler(+43): Thread: In
On 09/18/2013 10:31 PM, Maxim wrote:
> hi,
>
> but how do I find the problematic message?
By looking at the debug logs.
--
Paul J Stevenspjstevns @ gmail, twitter, skype, linkedin
* Premium Hosting Services and Web App
Здравствуйте, Maxim.
Вы писали 19 сентября 2013 г., 0:31:24:
> hi,
> but how do I find the problematic message?
> Вы писали 15 сентября 2013 г., 16:27:19:
>> I don't see anything obviously wrong here without doing a drill-down on
>> the backtrace. Can you provide steps to reproduce this? Is th
hi,
but how do I find the problematic message?
Вы писали 15 сентября 2013 г., 16:27:19:
> I don't see anything obviously wrong here without doing a drill-down on
> the backtrace. Can you provide steps to reproduce this? Is this related
> to a specific message? Of so, can you send me the message?
I don't see anything obviously wrong here without doing a drill-down on
the backtrace. Can you provide steps to reproduce this? Is this related
to a specific message? Of so, can you send me the message?
On 09/14/2013 11:00 PM, Maxim wrote:
>
> this?
>
> (gdb) bt
> #0 0x76cd5493 in g_lis
this?
(gdb) bt
#0 0x76cd5493 in g_list_last () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x76cd552e in g_list_append () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x75cc31ec in g_list_append_printf (list=0x3976514453745137,
format=0x75d08ade "\"%s\"") at d
I do not have time right now, a little later
14.09.13 16:19, Paul J Stevens пишет:
On 09/14/2013 02:13 PM, Maxim wrote:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe0060700 (LWP 8750)]
0x76cd5493 in g_list_last () from
/lib/x86_64-linux-gnu/libglib-2.
On 09/14/2013 02:13 PM, Maxim wrote:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffe0060700 (LWP 8750)]
> 0x76cd5493 in g_list_last () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
this is not enough. Please provide a full backtrace so I can figure
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe0060700 (LWP 8750)]
0x76cd5493 in g_list_last () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
14.09.13 15:51, Paul J Stevens пишет:
gdb src/dbmail-imapd
___
D
Yes, I know.
14.09.13 15:32, Reindl Harald ?:
with "file_logging_levels = 511" you have a*very very* fast growing log-*file*
on Fedora /var/log/dbmail.err and not a flooded syslog because this would become
rate-controlled and most likely miss relevant informations
watch out have this set
On 09/14/2013 01:27 PM, Maxim wrote:
>> it happens when I delete the cache in a large imap folder and try to
>> re-download the message.
Can you please do that while running imapd through gdb:
recompile with CFLAGS+=-g
# gdb src/dbmail-imapd
gdb> run -D
run the steps to produce the crash
gdb
Am 14.09.2013 13:23, schrieb Maxim:
> SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux
>
> Message in syslog:
> kernel: [ 1315.730257] pool[2999] general protection ip:7f6a9764a9e9
> sp:7f6a88bf7b78 error:0 in libdbmail.so.0.0.0 [7f6a97611000+6b000]
>
> and dbmail-imapd down.
>
> Another error mes
a, sorry
dbmail 3.1.6
14.09.13 15:23, Maxim:
hi,
SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux
Message in syslog:
kernel: [ 1315.730257] pool[2999] general protection ip:7f6a9764a9e9
sp:7f6a88bf7b78 error:0 in libdbmail.so.0.0.0 [7f6a97611000+6b000]
and dbmail-imapd down.
Another error mes
On 2013-09-09 10:08, Paul J Stevens wrote:
On 09-09-13 08:27, Thomas Raschbacher wrote:
write(13, "Q", 1) = -1 EAGAIN (Resource
temporarily unavailable)
read(25, 0x1843e70, 11) = -1 EAGAIN (Resource
temporarily unavailable)
Thomas,
could you please test
On 09-09-13 13:43, Harald Leithner wrote:
> this could be normal, but strange normal this high cpu usage is for a
> short time. Now its much longer.
Looks ok to me. Using locks will result in higher CPU, but hopefully no
more spin-locks.
Must find a better inter-thread notification mechanism tha
On 09-09-13 15:41, Harald Leithner wrote:
> does this mean I have 50 user connections running?
>
No. Some of them will be database connection, but most indeed will be
client-connections.
Use netstat, not lsof to find out which is which:
netstat -anlp|grep `pidof dbmail-imapd`
--
___
does this mean I have 50 user connections running?
l-wx-- 1 root root 64 Sep 9 15:38 0 -> /var/log/dbmail/dbmail.log
l-wx-- 1 root root 64 Sep 9 15:38 1 -> /var/log/dbmail/dbmail-imap.log
lrwx-- 1 root root 64 Sep 9 15:38 10 -> anon_inode:[eventfd]
lr-x-- 1 root root 64 Sep 9
you could have a look at what those file handles are (pipe, file,
socket,..)
e.g. I get this for imapd:
ls -l /proc//fd
insgesamt 0
lr-x-- 1 root root 64 9. Sep 14:06 0 -> /dev/null
l-wx-- 1 root root 64 9. Sep 14:06 1 -> /var/log/dbmail.log
lrwx-- 1 root root 64 9. Sep 14:06 10
I'm not sure but it seam to need much more cpu time now.
also pop3d at 100% with:
write(16, "gkJCTwvZGljdD4KCQk8L2Fy\r\ncmF5Pgo"..., 262143) = -1 EAGAIN
(Resource temporarily unavailable)
imapd at 200% with:
write(13, "Q", 1) = 1
write(34, "\27\3\1\0 \247\310\373\364\20
On 2013-09-09 10:08, Paul J Stevens wrote:
On 09-09-13 08:27, Thomas Raschbacher wrote:
write(13, "Q", 1) = -1 EAGAIN (Resource
temporarily unavailable)
read(25, 0x1843e70, 11) = -1 EAGAIN (Resource
temporarily unavailable)
Thomas,
could you please test
On 09-09-13 08:27, Thomas Raschbacher wrote:
>> write(13, "Q", 1) = -1 EAGAIN (Resource
>> temporarily unavailable)
>> read(25, 0x1843e70, 11) = -1 EAGAIN (Resource
>> temporarily unavailable)
Thomas,
could you please test 4c23432cc270554557f9e130331214d8116
On 2013-09-09 08:10, Thomas Raschbacher wrote:
hi.
It happened again at ~ 03:00 this morning.
I did save a proper core file + more strace this time:
strace:
...
write(13, "Q", 1) = -1 EAGAIN (Resource
temporarily unavailable)
read(25, 0x1843e70, 11) = -1
hi.
It happened again at ~ 03:00 this morning.
I did save a proper core file + more strace this time:
strace:
...
write(13, "Q", 1) = -1 EAGAIN (Resource
temporarily unavailable)
read(25, 0x1843e70, 11) = -1 EAGAIN (Resource
temporarily unavailable)
...
On 09/05/2013 04:10 PM, Thomas Raschbacher wrote:
> write(13, "Q", 1) = -1 EAGAIN (Resource
This is the one I wanted to see.
--
Paul J Stevenspjstevns @ gmail, twitter, skype, linkedin
* Premium
On 2013-09-05 13:53, Paul J Stevens wrote:
On 09/05/2013 01:18 PM, Thomas Raschbacher wrote:
strace shows exactly the same again.
Sure?? Please show me.
I don't have a lot anymore but basically this again over and over:
read(4, 0x1efbca0, 11) = -1 EAGAIN (Resource
temporar
On 09/05/2013 01:18 PM, Thomas Raschbacher wrote:
> strace shows exactly the same again.
Sure?? Please show me.
--
Paul J Stevenspjstevns @ gmail, twitter, skype, linkedin
* Premium Hosting Services and Web Applicatio
still the same problem with 3.1.4
strace shows exactly the same again.
Anything I can do to help you debug this selfpipe problem?
On 2013-08-28 20:58, Thomas Raschbacher wrote:
FYI, this just happened again a few minutes ago.
I do have a daily cron script that does restart dbmail daemons, even
Am 11.02.2013 12:24, schrieb Michael Monnerie:
> User reported "can't connect via imap", and the imapd process was gone.
>
> dmesg shows this:
>
> [4403546.139853] dbmail-imapd[3447]: segfault at 7fff73fad8e0 ip
> 0041015a sp 7fff73fad8d0 error 6 in dbmail-imapd[40+19000]
> [63
On 04/12/2012 10:39 AM, Reindl Harald wrote:
> testserver started build, considering deploy after some tests today
> is the value in bytes like postfix's "message_size_limit = 36700160"?
Yes, so *no* 'magic' interpretation of M, G, or other postfixes.
You *can* use: base-10, hexadecimal, and oct
Am 12.04.2012 10:07, schrieb Paul J Stevens:
> On 04/11/2012 05:19 PM, Reindl Harald wrote:
>
>> that would be perfect and trigger the error before the
>> composer has finsihed and press "send"
>
>
> Added in patch:
>
> http://git.dbmail.eu/paul/dbmail/commit/?id=e8edcb868150da613fb2fd89fece0
On 04/11/2012 05:19 PM, Reindl Harald wrote:
> that would be perfect and trigger the error before the
> composer has finsihed and press "send"
Added in patch:
http://git.dbmail.eu/paul/dbmail/commit/?id=e8edcb868150da613fb2fd89fece0956fc7c93f0
--
__
On Wed, 11 Apr 2012 10:51:58 +0200
Paul J Stevens wrote:
> On 04/11/2012 10:42 AM, Paul J Stevens wrote:
>
> > Please file a bug, if you will.
>
> No need. Fixed already.
Confirming that the fix works.
--
Jure Pečar
http://jure.pecar.org
http://f5j.eu
__
Am 11.04.2012 17:09, schrieb Paul J Stevens:
> After testing with 100MB size message appends I came up with:
> http://git.dbmail.eu/paul/dbmail/commit/?id=4b095dbcb956aa3538b21912ba34b0db088e4967
> which will improve the situation, but *not* fix it completely.
>
> The OOM situation is caused by
On 04/11/2012 03:00 PM, Reindl Harald wrote:
>
>
> Am 11.04.2012 10:51, schrieb Paul J Stevens:
>> On 04/11/2012 10:42 AM, Paul J Stevens wrote:
>>
>>> Please file a bug, if you will.
>>
>> No need. Fixed already.
>
> does this also fix the (reintroduced) problem to stop
> if a client tries to s
On 04/11/2012 03:00 PM, Reindl Harald wrote:
>
>
> Am 11.04.2012 10:51, schrieb Paul J Stevens:
>> On 04/11/2012 10:42 AM, Paul J Stevens wrote:
>>
>>> Please file a bug, if you will.
>>
>> No need. Fixed already.
>
> does this also fix the (reintroduced) problem to stop
> if a client tries to s
Am 11.04.2012 10:51, schrieb Paul J Stevens:
> On 04/11/2012 10:42 AM, Paul J Stevens wrote:
>
>> Please file a bug, if you will.
>
> No need. Fixed already.
does this also fix the (reintroduced) problem to stop
if a client tries to store a > 500 MB message in the
dafts folder?
i tried this y
On 04/11/2012 10:42 AM, Paul J Stevens wrote:
> Please file a bug, if you will.
No need. Fixed already.
--
Paul J Stevenspjstevns @ gmail, twitter, skype, linkedin
* Premium Hosting Services and Web Application Consulta
On 04/10/2012 05:37 PM, Jure Pečar wrote:
> C: A0005 APPEND Sent (\Seen) {12824}
> S: + OK
> C: MIME-Version: 1.0
>
>
> So roundcube is right in freezing, since it waits for a reply from
> imap server that never comes. Looking at this protocol dialog, server
> is misleading the client when it r
On 04/04/2012 01:19 PM, Douglas Stanley wrote:
> There's also supervisord which can monitor things like memory usage too.
> You need to be able to run the daemon in the foreground to use it though.
That's what the -D switch is for on all daemons: to support running from
inittab/daemontools/supervi
There's also supervisord which can monitor things like memory usage too.
You need to be able to run the daemon in the foreground to use it though.
Doug
On Apr 3, 2012 9:18 PM, wrote:
> If you don't want to restart the service manually by hand to recover from
> a crash you can always take advant
this is not needed on machines with systemd
the daily restart is to prevent IMAPd crash after
some days and eating up the servers RAM what can
lead to OOM-killer troubles under pressure
better a scheudled regular restart than random crash
what all this can not fix is having the process
running b
If you don't want to restart the service manually by hand to recover
from a crash you can always take advantage of daemon tools, by dj
berstien. It is a set of tools that monitor a process and restart it
in the event that the process stops working.
That is a temporary fix until a patch is release
hmm... daily restarting is a good workaround for now.
thx
Harald
Am 02.04.2012, 12:32 Uhr, schrieb Reindl Harald :
imapd has currently memory leaks and is growing over
some hundret MB up to > 1 GB memory after few days
the crash is easy to solve by systemd-autorestart
last sunday it stopped a
imapd has currently memory leaks and is growing over
some hundret MB up to > 1 GB memory after few days
the crash is easy to solve by systemd-autorestart
last sunday it stopped accepting connections around
12AM and i happily was in front of my machine for
restart the daemon - in this state all mai
Il 29/08/10 19.31, Paul J Stevens ha scritto:
> Ettore,
>
> this is a know bug. To work around use
>
> #bindip = 0.0.0.0# IPv4 only - all IP's
> #bindip = :: # IPv4 and IPv6 - all IP's (linux)
> #bindip = :: # IPv6 only - all IP's (BSD)
> #bindip
Ettore,
this is a know bug. To work around use
#bindip = 0.0.0.0# IPv4 only - all IP's
#bindip = :: # IPv4 and IPv6 - all IP's (linux)
#bindip = :: # IPv6 only - all IP's (BSD)
#bindip = 0.0.0.0,:: # IPv4 and IPv6 - all IP's (BSD)
the code
On 07/20/2010 03:56 PM, Victor wrote:
> Thank you Paul J Stevens very much.
> I have rebuilt dbmail and all works correctly.
Excellent. Thanks for your help and patience.
> Tell me please, when will new version (2.2.17) of dbmail issue?
I'll try to get it out later this week.
>
>> Viktor,
>
Thank you Paul J Stevens very much.
I have rebuilt dbmail and all works correctly.
Tell me please, when will new version (2.2.17) of dbmail issue?
> Viktor,
>
> looks like your problem was indeed IMAP-APPEND. You can get the patch I
> did today from:
>
> http://git.dbmail.eu/cgit/cgit.cgi/paul
Viktor,
looks like your problem was indeed IMAP-APPEND. You can get the patch I
did today from:
http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/patch/?id=793da8e1a12fecbfbf3a7c0aebfe64e4e1eefdfd
But you might as well pull in the whole 2.2 tree:
git clone -b dbmail_2_2 git://git.dbmail.eu/paul/d
I ran dbmail with trace_syslog=4 and attached trace.log file below.
Can you send me a patch which fix this problem ?
Or should I wait a new version of dbmail?
http://old.nabble.com/file/p29213476/trace.log trace.log
--
View this message in context:
http://old.nabble.com/IMAPD-uses-100--CPU-if-
I would really like to see the IMAP command replay for this problem.
Running at trace_syslog=4 should log them.
I've also just committed a major improvement in the IMAP-APPEND code.
Turned out the alarm handler was reset after every char read from the
wire :-(
Been testing with a 100MB message on
Harald is right, this problem is not in difference of mail clients.
I try to send mail via dbmail-smtp and result is the same. dbmail-imapd uses
100% CPU.
Bugzilla from h.rei...@thelounge.net wrote:
>
> Am 18.07.2010 20:25, schrieb Paul J Stevens:
>> On 07/17/2010 06:01 PM, Reindl Harald wrote:
Am 18.07.2010 20:25, schrieb Paul J Stevens:
> On 07/17/2010 06:01 PM, Reindl Harald wrote:
>> I can confirm this and it seems there are different
>> handlings between mail-clients
>
> Harald,
>
> exactly what are you confirming?
That dbmail-imapd is using 100% cpu while handling big
attachments
On 07/17/2010 06:01 PM, Reindl Harald wrote:
> I can confirm this and it seems there are different
> handlings between mail-clients
Harald,
exactly what are you confirming?
Since dbmail-lmtpd and dbmail-imapd are completely separate processes I
have a hard time coming up with a likely scenario t
I used php based web interface roundcube, squirrelmail and evolution.
All mail clients invoke this error in dbmail-imapd when message is sending.
But if I send message which was already sent and it lay in the sent folder,
there is NO this error.
In log I see following:
1.Message is sendi
I can confirm this and it seems there are different
handlings between mail-clients
* thunderbird takes a really long time and freezes
* horde-webmail is fast and let download the attachment normally
Maybe theres is some difference how both clients fetch
attachments and one of them possible could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul J Stevens schrieb:
First:
Thank you for the great software and yes i know that it is not easy to get away
all bugs
in all situations because i'm web-developer and i say only "ms internet
explorer"
I love the idea to have all in a database and
On Mittwoch 12 August 2009 Reindl Harald wrote:
> As the disk ran full it was configured to 1000 and i configured to 25
> because i am hoping that the processes owning the temp-files will die
> earlier, but there are also 5 GB of deleted temp-data
>
> What is wrong in my logic?
> If i restart imapd
Reindl Harald wrote:
>
> Paul J Stevens schrieb:
>
>> This was discussed on the list some time ago. Please try searching the
>> list archives.
>
>> IIRC, It is a bug that is probably triggered by a very low value for
>> MAXCONNECTS in dbmail.conf
>
> Hi
>
> As the disk ran full it was configur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul J Stevens schrieb:
> This was discussed on the list some time ago. Please try searching the
> list archives.
>
> IIRC, It is a bug that is probably triggered by a very low value for
> MAXCONNECTS in dbmail.conf
Hi
As the disk ran full it was
On Mittwoch 12 August 2009 Reindl Harald wrote:
> Hm - I think there is a bug because the files are marked as deleted
> but space is allocated
No, that is intended. This is a security measure, as nobody else can
access the files anymore. As soon as you stop the daemons, the space
will be freed a
Reindl,
This was discussed on the list some time ago. Please try searching the
list archives.
IIRC, It is a bug that is probably triggered by a very low value for
MAXCONNECTS in dbmail.conf
Reindl Harald wrote:
>
> Hm - I think there is a bug because the files are marked as deleted but
> space
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hm - I think there is a bug because the files are marked as deleted but
space is allocated
Michael Monnerie schrieb:
> On Mittwoch 12 August 2009 Reindl Harald wrote:
>> Has anybody an idea if there is a screw to reduce temp-usage
>>
>> Last friday
On Mittwoch 12 August 2009 Reindl Harald wrote:
> Has anybody an idea if there is a screw to reduce temp-usage
>
> Last friday the disk was full and i had to restart dbmail-imapd
> There are many files which are "deleted" and only seen with lsof
I think the only thing is to resize that partition o
Simon Gray wrote:
> We're also occasionally receiving the same: Error:[imap]
> imap4.c,IMAPClientHandler(+307): command return with error [idle]
You can ignore those. Could be a client hanging up without logging out,
or issuing a valid 'DONE' response.
> I'll change to 2.2.11.rc-3, trace_stderr=
Ok, nothing to worry about. The \Recent flag on messages will be
incorrect, but no information is lost.
The culprit:
Nov 6 14:38:58 mail4-core-2 dbmail/imap4d[15280]: Debug:[sql]
dbmysql.c,db_query(+287): query [UPDATE dbmail_messages SET recent_flag
= 0 WHERE message_idnr IN
(21490,
>It looks like you have either a db schema issue, or database server problem.
>
>Please do a show create table dbmail_messages;
>You should have a recent_flag field.
>If you are missing that field (unlikely) do a alter table
>dbmail_messages add column `recent_flag` tinyint(1) NOT NULL DEFAULT '0'
It looks like you have either a db schema issue, or database server problem.
Please do a show create table dbmail_messages;
You should have a recent_flag field.
If you are missing that field (unlikely) do a alter table
dbmail_messages add column `recent_flag` tinyint(1) NOT NULL DEFAULT '0';
Y
Jon Duggan wrote:
>>> I have had a few occasions where users say they have lost email, are these
>>> errors possibly related?
>> That would be the first time, afaik. I can't tell if there's a relation.
>
> This possibly isn’t dbmail related (could be our spam filtering)
>
>> Next time you see th
>> I have had a few occasions where users say they have lost email, are these
>> errors possibly related?
>
>That would be the first time, afaik. I can't tell if there's a relation.
This possibly isn’t dbmail related (could be our spam filtering)
>Next time you see this error, try find out what
Jon Duggan wrote:
> Hi Paul,
>
> Thanks for the swift response.
>
> This is DBMail version 2.2.10
>
> I have had a few occasions where users say they have lost email, are these
> errors possibly related?
That would be the first time, afaik. I can't tell if there's a relation.
The logs you sent
s) on debian etch.
If you need any further information let me know.
TIA
Jon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul J Stevens
Sent: 06 November 2008 11:35
To: DBMail mailinglist
Subject: Re: [Dbmail] imapd error
Not good.
What version ar
Not good.
What version are you running?
Jon Duggan wrote:
> Hey guys,
>
>
>
> (Apologise if this is a duplicate post – I don’t see my first attempt at
> time of writing and believe the attachment may have been too big)
>
>
>
> After digging through logs for an unrelated problem i came a
umask wrote:
> Bernard, how I can get stacktrace?
> In my case dbmail-imapd receive SIGHUP which send logrotate at 04:10 AM every
> week.
Run it under a debugger (gdb). If it terminates abnormally, type 'bt'
in the debugger to get the trace.
If it exits normally, then we have other issues :)
_
27.08.07, 06:28, Bernard Johnson ([EMAIL PROTECTED]):
> umask wrote:
> > We're uging DBMail 2.2.5 from EPEL (Extra Packages for Enterprise Linux by
> > RedHat/Fedora Project) -
> > http://download.fedora.redhat.com/pub/epel/5/i386/repoview/dbmail.html .
> >
> > Sources of dbmail from EPEL con
umask wrote:
> We're uging DBMail 2.2.5 from EPEL (Extra Packages for Enterprise Linux by
> RedHat/Fedora Project) -
> http://download.fedora.redhat.com/pub/epel/5/i386/repoview/dbmail.html .
>
> Sources of dbmail from EPEL contains next patch:
> begin patch
[patch delet
On Fri, 2006-12-08 at 04:01 -0800, Michael Dean wrote:
> Ryan, which imapd are you running again?
Path: .
URL: https://svn.ic-s.nl/svn/dbmail/branches/dbmail_2_2_branch
Repository Root: https://svn.ic-s.nl/svn/dbmail
Repository UUID: 7b491191-dbf0-0310-aff6-d879d4d69008
Revision: 2361
Node Kind: d
Paul J Stevens wrote:
Ryan Butler wrote:
9853 dbmail15 0 679m 46m 660 S 0.0 9.3 5:33.60
dbmail-imapd
679 meg!
There's only about 12 people who use this on a mail store of about 3 or
4 gig. Most are running either thunderbird or evolution. The process
was started sometime on
Ryan Butler wrote:
> 9853 dbmail15 0 679m 46m 660 S 0.0 9.3 5:33.60
> dbmail-imapd
>
> 679 meg!
>
> There's only about 12 people who use this on a mail store of about 3 or
> 4 gig. Most are running either thunderbird or evolution. The process
> was started sometime on the 6th so
On Tue, 2006-12-05 at 21:47 +0100, Paul J Stevens wrote:
> Justin McAleer wrote:
> >
> > Per my other email in this thread, issue 462 was opened
> > on 11/29/06 about this problem.
>
> Justin, please upload a loglevel 5 trace containing some FETCH commands.
>
Just as another datapoint, I've
Aaron Stone wrote:
Let's not forget to file a bug, btw... ;-)
yeah... I was meaning to mention that to you.
I had a little trouble signing up and at the time I wasn't able to really chase
it much (right before work).
I created a new login and it says it succeeded.
I think the email might
No problem. I kicked off Thunderbird's junk mail filtering
on my inbox, and I grabbed two messages' worth of level 5
traces. It's attached to the issue now. Let me know if you
want to see anything else.
On Tue, 05 Dec 2006 21:47:41 +0100
Paul J Stevens <[EMAIL PROTECTED]> wrote:
> Justin McAleer
Justin McAleer wrote:
>
> Per my other email in this thread, issue 462 was opened
> on 11/29/06 about this problem.
Justin, please upload a loglevel 5 trace containing some FETCH commands.
--
Paul Stevens
Comment inline.
On Tue, 5 Dec 2006 18:06:20 -
"Aaron Stone" <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 5, 2006, Tom Allison <[EMAIL PROTECTED]> said:
>
> > Jake Anderson wrote:
> >> jurgen wrote:
> >>> Hi,
> >>>
> >>> I've got dbmail 2.2.1 + mysql 4.1.21 running on a
> relatively
> >>> up-to-d
On Tue, Dec 5, 2006, Tom Allison <[EMAIL PROTECTED]> said:
> Jake Anderson wrote:
>> jurgen wrote:
>>> Hi,
>>>
>>> I've got dbmail 2.2.1 + mysql 4.1.21 running on a relatively
>>> up-to-date Gentoo box. After some hours of use, dbmail-imapd starts
>>> slowly gobbling more and more of my RAM. Event
List emails to bring up an issue, but once we determine there's a bug,
I'm pushing for bug reports before making code changes. The goal is to
have most/all of the code changes in 2.2.x releases pinned to bug
reports, to keep track of what's going on between releases.
Bug reports are also better pl
I filed a bug report (issue 462) about this last
Wednesday and it hasn't been updated yet. I've noticed a
few times where you've responded to list messages telling
people to file a report; do you prefer a list email prior
to formally reporting a bug?
On Tue, 05 Dec 2006 10:07:26 +0100
Paul J
Jake Anderson wrote:
jurgen wrote:
Hi,
I've got dbmail 2.2.1 + mysql 4.1.21 running on a relatively
up-to-date Gentoo box. After some hours of use, dbmail-imapd starts
slowly gobbling more and more of my RAM. Eventually, this gets
completely out of control, we enter paging-hell for a few minute
Jake Anderson wrote:
> However looking at the memory usage on the "from" machine the
> dbmail-imapd process starts chewing memory like crazy. After about 5000
> messages it reaches the limit of memory and everything stops. What can I
> do to find the problem?
Find one of the exact FETCH commands
jurgen wrote:
> Hi,
>
> I've got dbmail 2.2.1 + mysql 4.1.21 running on a relatively
> up-to-date Gentoo box. After some hours of use, dbmail-imapd starts
> slowly gobbling more and more of my RAM. Eventually, this gets
> completely out of control, we enter paging-hell for a few minutes, and
> ulti
From: Paul J Stevens <[EMAIL PROTECTED]>
Reply-To: DBMail mailinglist
To: DBMail mailinglist
Subject: Re: [Dbmail] imapd defunct processes
Date: Thu, 26 Oct 2006 22:58:13 +0200
Jim Douglas wrote:
>
> Prior to the package upgrade dbmail worked for 2-3 weeks, no problem.
Jim,
What
Jim Douglas wrote:
>
> Prior to the package upgrade dbmail worked for 2-3 weeks, no problem.
Jim,
What versions are you running now for:
libmysqlclient
libglib2
libgmime2
glibc6
Is anyone else running dbmail_2_2_branch on fedora-5?
Other than that: are you seeing any errors being logged by db
From: Jake Anderson <[EMAIL PROTECTED]>
Reply-To: DBMail mailinglist
To: DBMail mailinglist
Subject: Re: [Dbmail] imapd defunct processes
Date: Fri, 27 Oct 2006 00:35:27 +1000
Dominic Amann wrote:
After some minutes of operation, I have some 80 defunct process (out of
100) of dbmail-ima
Dominic Amann wrote:
After some minutes of operation, I have some 80 defunct process (out
of 100) of dbmail-imapd. It does not seem happen when I connect my
e-mail client (thunderbird), but it happens at some point soon after,
possibly when the local LAN users begin to connect.
What does this
Which dbmail version?
Jochen,
I just got back from a vacation. It'll take a couple of days before I
can start working on dbmail bugs again.
Jochen Entenmann wrote:
> Hi Paul,
>
> I have still this errors:
> =
> dbmail-imapsession.c,dbmail_imap_session_readln: error reading from client
> im
This also happens to me.
- Original Message -
From: "Jochen Entenmann" <[EMAIL PROTECTED]>
To: "'DBMail mailinglist'"
Sent: Friday, July 28, 2006 11:13 AM
Subject: [Dbmail] Imapd errors
Hi Paul,
I have still this errors:
=
dbmail-imapsession.c,dbmail_i
VEL=1
- Original Message -
From: "Paul J Stevens" <[EMAIL PROTECTED]>
To: "DBMail mailinglist"
Sent: Monday, July 24, 2006 4:40 PM
Subject: Re: [Dbmail] ImapD problem
Jorge, how is your TIMEOUT setup in dbmail.conf?
Jorge Bastos wrote:
Paul, here's a
gt; To: "DBMail mailinglist"
> Sent: Monday, July 24, 2006 8:51 AM
> Subject: Re: [Dbmail] ImapD problem
>
>
>> Jorge,
>>
>> There's absolutely nothing I can do without a level5 log.
>>
>>
>> Jorge Bastos wrote:
>>> Hi Paul,
&
1 - 100 of 151 matches
Mail list logo
