forget to enable it.
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
On 02/10/2010 06:15 PM, Brandon Davidson wrote:
Hi David,
-Original Message-
From: David Halik
It looks like we're still working towards a layer 7 solution anyway.
Right now we have one of our student programmers hacking Perdition
with
a new plugin for dynamic username
Or you can run any TB 3 version, just turn off CONDSTORE support in the
config. Doing so won't hurt anything.
On 2/8/2010 8:35 AM, Christian Rohmann wrote:
Hello,
On 02/08/2010 01:54 PM, Holger wrote:
Is this problem Dovecot related ?
Do you have the same trouble ?
Yes and I
On 02/06/2010 02:32 PM, Timo Sirainen wrote:
On Sat, 2010-02-06 at 14:28 -0500, David Halik wrote:
On 2/6/2010 2:06 PM, Timo Sirainen wrote:
ab9e0, st=0x7fffc949d4b0) at maildir-uidlist.c:382
Oh, interesting. An infinite loop. Looks like this could have happened
ever since v1.1
On 02/08/2010 01:46 PM, Brandon Davidson wrote:
Hi David,
-Original Message-
From: David Halik
I've been running both patches and so far they're stable with no new
crashes, but I haven't really seen any better behavior, so I don't
know if it's accomplishing anything. =)
Still
On 2/6/2010 2:06 PM, Timo Sirainen wrote:
ab9e0, st=0x7fffc949d4b0) at maildir-uidlist.c:382
Oh, interesting. An infinite loop. Looks like this could have happened
ever since v1.1. Wonder why it hasn't shown up before. Anyway, fixed:
http://hg.dovecot.org/dovecot-1.2/rev/a9710cb350c0
to end up being what we use to avoid NFS
problems. It's lightweight, drops into our current setup, and doesn't
require a mysql database which adds another point of failure.
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
message.
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
On 2/1/2010 5:47 PM, Timo Sirainen wrote:
On 2.2.2010, at 0.39, David Halik wrote:
Back to dovecot, actually sqlite might work, because then I don't need a
database backend, just a local sqlite regex. The question then being, how would
dovecot handle multiple servers? For example
in main (argc=value optimized out, argv=value
optimized out, envp=0x7fff2d949c18) at main.c:327
No locals.
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
to live with it until I either get proxy_maybe
setup, or some other solution.
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
On 01/25/2010 01:00 PM, Charles Marcus wrote:
On 2010-01-25 12:57 PM, David Halik wrote:
I just had user experience this with TB 2, and after looking at the logs
I found the good ole' stale nfs message:
Maybe TB3 would be better behaved? It has many, many MAP improvements
over TB2
On 01/25/2010 01:02 PM, David Halik wrote:
On 01/25/2010 01:00 PM, Charles Marcus wrote:
On 2010-01-25 12:57 PM, David Halik wrote:
I just had user experience this with TB 2, and after looking at the
logs
I found the good ole' stale nfs message:
Maybe TB3 would be better behaved? It has many
On 01/25/2010 02:18 PM, David Halik wrote:
On 01/25/2010 01:31 PM, Timo Sirainen wrote:
On Mon, 2010-01-25 at 12:57 -0500, David Halik wrote:
Jan 25 11:39:24 gehenna21 dovecot: IMAP(user):
fdatasync(/rci/nqu/rci/u8/user/dovecot/.INBOX/dovecot-uidlist) failed:
Stale NFS file handle
Well, two
On 01/25/2010 03:26 PM, Timo Sirainen wrote:
On Mon, 2010-01-25 at 15:12 -0500, David Halik wrote:
I patched and immediately starting seeing *many* of these:
Jan 25 15:05:33 gehenna18.rutgers.edu dovecot: IMAP(user):
lseek(/rci/nqu/rci/u1/sendick/dovecot/.Trash/dovecot-uidlist) failed:
Bad
No guts no glory! So far, so good. The first patch started spewing messages
within seconds. I've been running for about twenty minutes with this version
and I haven't seen much of anything yet.
I'll report back tomorrow after it has a day to burn in.
It's still a bit buggy. I haven't
So, what is the real world benefit of CONDSTORE? In other words, what do
you lose by disabling it?
My general understanding is that it reduces both client and server sync
load by essentially allowing the two to be smarter about flag/time
changes. When a client connects it does not need to
Well, I don't know how you feel about it, but you could always go with
something similar to what courier does and call it doveauth while
keeping the real dovecot user for the reset of the processes.
It's eight characters, reminds you of the login process, and very easy
to understand for
Seems everyone is starting to notice this now. :)
Yes, there are several flaws and bug reports open with Mozilla on broken
behavior with TB 3.0 and TB 3.0.1. Currently the easiest fix is to turn
off CONDSTOR either server side or in TB itself. There is also a TB
3.0.2pre nightly available
trying to fix it for the
last two releases. So far the alpha build for 3.0.2 is working for me.
https://bugzilla.mozilla.org/show_bug.cgi?id=517461
https://bugzilla.mozilla.org/show_bug.cgi?id=524902
--
David Halik
System Administrator
OIT-CSS Rutgers University
experience so far?
Thanks,
-Dave
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
suggested and we'll be thinking about long term solutions.
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
,
with noac being out of the question unless they buy a ridiculously
expensive filer.
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
not such a problem after all. Anyway, what has you experience
been?
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
idea?
On 01/20/2010 01:45 PM, Timo Sirainen wrote:
On 20.1.2010, at 20.24, David Halik wrote:
Jan 20 13:13:59 gehenna13.rutgers.edu dovecot: IMAP(user):
/rci/nqu/rci/u2/user/dovecot/.INBOX/dovecot-uidlist: Duplicate file entry at line
3: 1259771459.M806388P24066V04240001I002E8FC6_0
On 01/21/2010 12:14 PM, Timo Sirainen wrote:
On 21.1.2010, at 19.13, Timo Sirainen wrote:
On 21.1.2010, at 19.10, David Halik wrote:
This seems to have started since TB 3.0 came out. Especially, with the new
indexing feature they added. I'm not seeing it with Pine or SQMail
! ;)
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
.
Unfortunately, that was something we learned too late after we did our
migration. =)
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
such a large increase of load was too much to handle.
During the 12 hour window I didn't see a single uid error as expected,
but the fix was worse than the problem.
On 01/13/2010 07:41 PM, David Halik wrote:
Same here. I laughed because our help desk started sending us the
exact same complaints
Same here. I laughed because our help desk started sending us the exact
same complaints and then today I got a little bit of a red nose when a
director's mail disappeared in a meeting. ;) Whoops.
It looks like users who end up with the off by 1 uid list rebuild and
crash experience and
}
On 12/30/2009 12:10 PM, David Halik wrote:
Ok, I think I've got some more info and a more accurate time line for
you. I tried this on two different dumps from two different users. The
count was 4 in the first example and 0 in the second. I'm guessing
that's considered small? The links to my
of these issues up) is 10 dedicated IMAP/POP servers, 2 frontend
*nix boxes running pine, and four webmail machines using imapproxy to
connect to the IMAP servers... all using the same NFS backend. More than
likely it's an multi-server access NFS issue.
--
David Halik
System
, search_save_result = 0, temp_executed = 0}
(gdb) quit
- End forwarded message -
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
Hi Ralf, Timo commited a patch for this last week, give it a try. So far
it has stopped these crashes for me.
http://hg.dovecot.org/dovecot-1.2/rev/56dd8c276ed6
On 12/30/2009 4:54 AM, Ralf Hildebrandt wrote:
* Ralf Hildebrandtralf.hildebra...@charite.de:
I got about 20 (!) of these
/m59aacde4
On 12/29/2009 7:50 PM, Timo Sirainen wrote:
On 29.12.2009, at 19.09, David Halik wrote:
I'll definitely get back to you on this. Right now we're closed until after New
Years and I don't want to go updating the dovecot package on all of our servers
until we're all back at work. I did
...
On 12/24/2009 11:39 AM, David Halik wrote:
I should probably also post the messages leading up for reference.
Note that I did not see any stale NFS messages this time, but did get
the usual duplicate file messages:
Dec 24 10:43:07 gehenna11 dovecot: IMAP(user):
/rci/nqu/rci/u1/user/dovecot
On 12/29/2009 6:18 PM, Timo Sirainen wrote:
Wonder if there's a corresponding Expunged message reappeared, giving a
new UID (old uid=x) having Dupliate file entry .. (uid x - for each
log line? Meaning that the duplicate file entries are caused by those
reappearing messages? (And the
in io_loop_run (ioloop=0x16afb60) at ioloop.c:335
#15 0x00428f20 in main (argc=value optimized out, argv=value
optimized out, envp=0x7fff86f840b8) at main.c:327
And the full backtrace:
http://pastebin.com/f651f649e
--
David Halik
System Administrator
OIT
) [0x428f20] -
/lib64/libc.so.6(__libc_start_main+0xf4) [0x354301d994] -
/usr/libexec/dovecot/imap [0x419ac9]
Dec 24 10:44:38 gehenna11 dovecot: dovecot: child 19032 (imap) killed
with signal 6 (core dumped)
On 12/24/2009 11:26 AM, David Halik wrote:
Dec 23 11:05:44 gehenna18.rutgers.edu
Looks like you're running 1.2.8, the
maildir_uidlist_records_drop_expunge crash was fixed in 1.2.9. Upgrading
should fix your problem.
On 12/23/2009 5:29 AM, Anton Dollmaier wrote:
Hi all,
after inserting another sieve-rule, I get the following backtrace on
deliver.
The mail gets
] -
/lib64/libc.so.6(__libc_start_main+0xf4) [0x38af41d994] -
/usr/libexec/dovecot/imap [0x419ac9]
On 12/22/2009 08:17 PM, Timo Sirainen wrote:
On 22.12.2009, at 16.42, David Halik wrote:
I just double checked and we're seeing the same thing here, although we were never
running with noac
No symbol p in current context.
...and here's the full trace for reference
http://pastebin.com/f77189785
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
-0500, David Halik wrote:
Dec 23 11:18:32 gehenna17.rutgers.edu dovecot: IMAP(user2): Panic: file
cmd-list.c: line 242 (ns_get_listed_prefix): assertion failed: (match ==
IMAP_MATCH_YES)
Fixed: http://hg.dovecot.org/dovecot-1.2/rev/56dd8c276ed6
I'm seeing both of these dumps on multiple users now with 1.2.9, so I
went ahead and did backtraces for them both.
maildir_uidlist_records_array_delete panic: http://pastebin.com/f20614d8
ns_get_listed_prefix panic: http://pastebin.com/f1420194c
On 12/21/2009 12:43 PM, David Halik wrote
) has dropped by a factor
of 10.
-Brad
-Original Message-
From: dovecot-bounces+brandond=uoregon@dovecot.org [mailto:dovecot-
bounces+brandond=uoregon@dovecot.org] On Behalf Of David Halik
Sent: Tuesday, December 22, 2009 7:48 AM
To: dovecot@dovecot.org
Subject: Re: [Dovecot
==
IMAP_MATCH_YES)
Let me know if you need full backtraces from the core dump.
On 12/17/2009 02:06 PM, David Halik wrote:
On 12/17/2009 01:07 PM, Timo Sirainen wrote:
On Thu, 2009-12-17 at 12:49 -0500, David Halik wrote:
I applied those patches to my 1.2.8 installation before 1.2.9 was
released
:
passdb:
driver: pam
args: dovecot
userdb:
driver: passwd
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
On 12/17/2009 01:07 PM, Timo Sirainen wrote:
On Thu, 2009-12-17 at 12:49 -0500, David Halik wrote:
I applied those patches to my 1.2.8 installation before 1.2.9 was
released and that immediately fixed the expunge crash, but the
array_delete bug is still there.
Do you also see
: yes
subscriptions: yes
lda:
postmaster_address: postmas...@jla.rutgers.edu
auth default:
verbose: yes
debug: yes
passdb:
driver: pam
args: *
userdb:
driver: passwd
plugin:
quota: fs
fts: squat
fts_squat: partial=4 full=4
--
David Halik
at 11:51 -0400, David Halik wrote:
I did some more digging and here's the actual error that it fails with:
Apr 23 09:28:21 batman.rutgers.edu IMAP(kmech): : [ID 107833 mail.crit]
Panic: file squat-trie.c: line 441: assertion failed:
(!node-have_sequential)
Are you still getting
Timo,
I had another core dump randomly while doing a search with squat on. The
backtrace is in the link:
http://pastebin.com/fd59ae03
Thanks.
David Halik wrote:
Timo Sirainen wrote:
Did you happen to get a core dump? gdb backtrace would be helpful:
http://dovecot.org/bugreport.html
/dovecot.index.search.uids:
wrong indexid
David Halik wrote:
Timo,
I had another core dump randomly while doing a search with squat on.
The backtrace is in the link:
http://pastebin.com/fd59ae03
Thanks.
David Halik wrote:
Timo Sirainen wrote:
Did you happen to get a core dump? gdb backtrace would
- 0x193f04 - 0x193290 - 0xa4308 - 0x77368
Sorry for sending this in multiple emails, I'm trying to help someone
debug it and I'm not getting the info all at once.
David Halik wrote:
Just an update. After I restarted pine and went back into the same
folder to start the search over, I had
:
driver: passwd
plugin:
quota: fs
fts: squat
fts_squat: partial=4 full=4
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
My mistake, bad copy and paste:
# dovecot -n
# 1.1.13: /usr/local/etc/dovecot.conf
# OS: SunOS 5.9 sun4u
protocols: imap imaps pop3 pop3s
Charles Marcus wrote:
On 4/21/2009, David Halik (dha...@jla.rutgers.edu) wrote:
# OS: SunOS 5.9 sun4u protocols: imap imaps pop3 pop3s
ssl_disable
/dovecot.conf
# OS: Linux 2.6.23-gentoo-r9 x86_64 Gentoo Base System release 1.12.11.1
protocols: imaps
listen: [::]
...
etc...
--
David Halik
System Administrator
OIT-CSS Rutgers University
dha...@jla.rutgers.edu
. It's useful
when you have a couple thousand emails and want to do multiple searches
because each successive search is fast. We're actually running it on our
Sun boxes in preparation for running it on faster linux boxes though, so
I'm not to worried.
--
David
That did the trick! No more memory allocation issues. That you very much
for the patch and your help Timo. Should we expect the patch to be in
the final 1.2 release, or in a future version?
-Dave
Timo Sirainen wrote:
On Mar 26, 2009, at 1:00 PM, David Halik wrote:
Any thoughts
.
Thanks,
-Dave
David Halik wrote:
Unfortunately, the patch didn't help, BUT I've discovered some very
interesting things along the way that I think you'd like to hear:
1) The problem stems from certain emails with odd or badly formed
characters.
The reason I wasn't seeing it on one machine
it
would get an E2BIG and bump the memory over and over.
Timo Sirainen wrote:
On Sat, 2009-03-21 at 18:58 -0400, David Halik wrote:
Mar 21 18:43:57 er0.rutgers.edu IMAP(dhalik): : [ID 107833 mail.crit]
Panic: Trying to allocate 2147483648 bytes
Attached patch probably helps
Aborted (core dumped)
Thanks again Timo,
-Dave
Timo Sirainen wrote:
On Sat, 2009-03-21 at 18:58 -0400, David Halik wrote:
Mar 21 18:43:57 er0.rutgers.edu IMAP(dhalik): : [ID 107833 mail.crit]
Panic: Trying to allocate 2147483648 bytes
Attached patch probably helps
On 3/20/2009 6:26 PM, Timo Sirainen wrote:
Maybe you could try copying the libraries and using LD_LIBRARY_PATH (or
whatever it is in Solaris) to force using those libraries instead of the
default ones?
I could try that as a last resort, but I don't think it will help. We
build our own
Timo Sirainen wrote:
On Thu, 2009-03-19 at 15:25 -0400, David Halik wrote:
So far
everything is working smoothly, but when someone does a search through
directory with a large number of emails, dovecot dies and prints the
following message:
[ID 107833 mail.crit] Panic: Trying to allocate
: .
prefix: INBOX.
inbox: yes
list: yes
subscriptions: yes
auth default:
passdb:
driver: pam
args: *
userdb:
driver: passwd
plugin:
quota: fs
Any help would be appreciated!
Thanks,
-Dave
--
David Halik
System Administrator
OIT-CSS Rutgers University
Whoops, that would explain it since we've been testing with 1.1.3.
Thanks Timo, I'll upgrade and hopefully that will fix it.
Timo Sirainen wrote:
On Mon, 2008-11-24 at 10:45 -0500, David Halik wrote:
Nov 24 08:34:34 xxx.xxx.xxx.xxx dovecot: [ID 107833 mail.error]
auth-worker(default): pam
This was starting from a clean index, first opening pine on the NFS
Solaris 9 sparc machine, and then at the same time opening pine on my
Fedora 9 i386 workstation.
Why does it matter where you run Pine? Does it directly execute Dovecot
on the local machine instead of connecting via TCP?
as section.
I'm still not sure what the fatal error message was for, but it must
have been because of this since it has gone away.
David Halik wrote:
Hi all,
I just upgraded a couple of Fedora 9 workstations to try out 1.1.1
over NFS'd homedir's and I'm having trouble running dovecot
.
I have seen other corrupted error reports in the mail archive, but
they did not seem to be
exactly like this one.
--
David Halik
System Administrator
OIT-CSS Rutgers University
[EMAIL PROTECTED]
/dovecot-uidlist
Timo Sirainen wrote:
On Jun 18, 2008, at 9:12 PM, David Halik wrote:
Now this setup is just a test example and not exactly what we'll be
running in production, but it tipped up the problem either way. Since
the index is shared by both the Linux i386 machine and the sparc64
not permitted
That doesn't really tell me much though.
Any ideas? Is dovecot taking different arguments now so my rimapd line
isn't working properly?
Any help would be appreciated.
Thanks.
--
David Halik
System Administrator
OIT-CSS Rutgers University
[EMAIL
--
David Halik
System Administrator
OIT-CSS Rutgers University
[EMAIL PROTECTED]
http://www.digitalruin.net
72 matches
Mail list logo
