--
- João Assad
- ParPerfeito Comunicação LTDA
- http://www.parperfeito.com.br/
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
with replication.
I would be very interested in this solution as well.
I would also be interested in replication advice.
Thanks,
I too am very interested in this replication solution. Where can I get
the src and documentation ?
Regards,
João Assad
Cyrus Home Page: http
Sergio Devojno Bruder wrote:
João Assad wrote:
Sergio Devojno Bruder wrote:
AHA:
Sep 21 09:08:49 mupdate mupdate[17026]: IOERROR: mapping
/var/lib/imap/mailboxes.db file: Cannot allocate memory
Sep 21 09:08:49 mupdate mupdate[17026]: failed to mmap
/var/lib/imap/mailboxes.db file
I
/cyrus/mailing-list.html
Sorry , I missed the original post.
Is the original poster using Fedora or RHEL ?
Regards
--
- João Assad
- ParPerfeito Comunicação LTDA
- http://www.parperfeito.com.br/
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ
.658729: cyrusdb error
cyrus/imap[30082]: IOERROR: open on /imap/mboxes/H/user/658729/1.: Too
many open files
cyrus is started with ulimit -S -n 100
Regards,
João Assad
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http
[1503]: accepted connection
May 19 15:31:19 frontend3 imaps[11783]: kick_mupdate: can't connect to
target: Connection refused
It's because your master mailboxes.db is corrupted. The master server
will behave crazy.
--
- João Assad
- ParPerfeito Comunicação LTDA
,
--
- João Assad
- ParPerfeito Comunicação LTDA
- http://www.parperfeito.com.br/
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
every five minutes ... :(
Thanks for your input !
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
--
- João Assad
- ParPerfeito Comunicação LTDA
if you are really having the IOERROR I asked for you to check.
Thanks for any answers or pointers.
Regards,
--
- João Assad
- ParPerfeito Comunicação LTDA
- http://www.parperfeito.com.br/
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http
and didnt notice any problems.
Regards
--
- João Assad
- ParPerfeito Comunicação LTDA
- http://www.parperfeito.com.br/
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus
Derrick J Brashear wrote:
If anyone else wants to try this (I'd guess auth_unix use in mupdate
isn't common?)
I use saslauthd for authentication which then uses pam. Is there a way
to get rid of auth_unix ?
sasl_pwcheck_method: saslauthd
sasl_mech_list: PLAIN
Derrick J Brashear wrote:
auth_unix's purpose is for groups, not for something pam will do for
you. technically if you're not using unix groups for access control
you don't need any of the group functionality. Really, though, I
should figure out what the getgr*_r interface difference which is
sometimes mupdate exits with signal 11 . Im clueless why.
cyrus-2.2.12
gdb backtrace attached.
Regards,
João Assad
backtrace.gz
Description: application/gzip-compressed
nice nice, I'll commence testing tonight.
on a side note, regarding that old mmap problem.. Im still testing it.
Im pretty sure its some bug in fedora's mmap.
Derrick J Brashear wrote:
On Tue, 26 Apr 2005, João Assad wrote:
sometimes mupdate exits with signal 11 . Im clueless why.
cyrus-2.2.12
Derrick J Brashear wrote:
is there a munmap for every mmap
when I start cyrus, both mupdate master and slave comes up, so I get
cyrus/mupdate[2678]: MMAP at map_refresh: mmap(0, 408084480, PROT_READ,
MAP_SHARED, 8, 0) = 1098067968
cyrus/mupdate[2679]: MMAP at map_refresh: mmap(0, 408084480,
João Assad wrote:
yet another gdb backtrace of the mmap problem
http://www.gazzag.com/gdb.output2.gz
regards
Hey Derrick, did you find anything usefull in this last backtrace ?
Regards
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives
On a cyrus mupdate master server, dump the mailbox list with
ctl_mboxlist -d stop cyrus and delete mailboxes.db and db/* , start
cyrus to create a new mailboxes.db
reimport all the data with ctl_mboxlist -u dump.
all the data will be there, you can even dump it again and compare the
dumps but
João Assad wrote:
also repeating the same process on one of the backends works
perfectly. It seems to be master related only.
do_undump in ctl_mboxlist.c have this:
mboxlist_makeentry(0, partition, acl);
making the mailboxes always type 0 , never type remote
there should be another option
yet another gdb backtrace of the mmap problem
http://www.gazzag.com/gdb.output2.gz
regards
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
João Assad wrote:
This doesnt seem to be related to the mmap problem
The only errors I got on cyrus log when it happened were a bunch of this:
Apr 10 16:35:03 cyrus-fe1 cyrus/lmtp[30983]: mupdate-client:
connect(10.1.5.101): Connection timed out
This time I have strace and gdb logs. Im sending
got a full gdb backtrace of the mmap crash.
Its 400k so you can download it from:
http://www.gazzag.com/gdb.output.gz
regards
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
This doesnt seem to be related to the mmap problem
The only errors I got on cyrus log when it happened were a bunch of this:
Apr 10 16:35:03 cyrus-fe1 cyrus/lmtp[30983]: mupdate-client:
connect(10.1.5.101): Connection timed out
This time I have strace and gdb logs. Im sending attached the last
Henrique de Moraes Holschuh wrote:
Just thought of something. Please set the
vm.overcommit_memory syscall to 2 (it is available in /proc/sys, I think.
But the right way is to use /etc/sysctl.conf and sysctl).
Make *really* sure you have enough swap when you do that. You will *really*
need it.
Out of curiosity..
everytime cyrus needs to mmap/munmap something. it uses its mmap
encapsulation, which is map_refresh and map_free.
So every once in a while I get this on strace.
14:27:02.148097 munmap(0x54968000, 373915648) = 0
14:27:02.148765 mmap2(NULL, 373932032, PROT_READ, MAP_SHARED, 8,
João Assad wrote:
Managed to get a backtrace using debug_command ( thanks for this nifty
feature Henrique de Moraes )
2 gdb backtraces from the production server.
#18988 0x0804dcd3 in fatal (
s=0x8d52f070 Internal error: assertion failed: mupdate.c: 586: 0,
code
João Assad wrote:
Managed to get a backtrace using debug_command ( thanks for this nifty
feature Henrique de Moraes )
and now a strace from the production server.. Im sending just the last few
lines of it. its really big.
16:18:02.399469 accept(4, 0, NULL) = 104
16:18:02.470386 getpeername
João Assad wrote:
Derrick J Brashear wrote:
On Fri, 8 Apr 2005, João Assad wrote:
João Assad wrote:
Managed to get a backtrace using debug_command ( thanks for this
nifty feature Henrique de Moraes )
2 gdb backtraces from the production server.
curiously, the strace output isn't showing an mmap
João Assad wrote:
Derrick J Brashear wrote:
curiously, the strace output isn't showing an mmap() call fail, that
I see, before the error shows up.
I could do a strace -f wich would dump all the traces from all the
threads into a single file... but its a nightmare to read it.
by reading some
Derrick J Brashear wrote:
So, prior to this presumably you've mmap2()'d some memory, have there
been any munmaps
for these mmap2s
00:25:58.583761 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb68e8000
00:25:58.585461 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
Derrick J Brashear wrote:
On Wed, 6 Apr 2005, João Assad wrote:
and then give us a backtrace from the core which you will then get?
After doing that, the mupdate process now exits with signal 11 as
expected.
OTOH the core isnt getting dumped to disk for some reason...
The only internal
Derrick J Brashear wrote:
On Wed, 6 Apr 2005, João Assad wrote:
and then give us a backtrace from the core which you will then get?
After doing that, the mupdate process now exits with signal 11 as
expected.
OTOH the core isnt getting dumped to disk for some reason...
The only internal
Derrick J Brashear wrote:
On Thu, 7 Apr 2005, João Assad wrote:
Ok I got a backtrace ( I think ) . I dont really know how to use gdb
did you compile without giving gcc the -g option? Probably. Having
unstripped binaries with useful symbols would probably make for a more
useful backtrace
João Assad wrote:
Derrick J Brashear wrote:
On Thu, 7 Apr 2005, João Assad wrote:
Ok I got a backtrace ( I think ) . I dont really know how to use gdb
did you compile without giving gcc the -g option? Probably. Having
unstripped binaries with useful symbols would probably make for a
more useful
.
What Im planning to do next is get a new server, install debian in it (
Im using Fedora core 2) and see if I have the same poroblem.
Regards,
João Assad
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus
Derrick J Brashear wrote:
I've noticed that once I get the mmap error, the system will still
run without spitting db errors for anywhere from a few mins to a few
hours. Also, I never get more than one mmap error before the db
becomes unnusable.
that's not shocking. i'd still like to know why
João Assad wrote:
The system have plenty of RAM available and ulimit -a reports the max
virtual memory as unlimited
core file size(blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 32
max memory size
Henrique de Moraes Holschuh wrote:
On Thu, 31 Mar 2005, Sergio Devojno Bruder wrote:
We've done 2 murder instalations, cyrus 2.2.3 and cyrus 2.2.10, and already
have seen the same type of corruption. (should ADD or DELETE), but not with
the same frequency.
Are you guys running the same
Derrick J Brashear wrote:
On Thu, 31 Mar 2005, João Assad wrote:
My db just got corrupted again 2 hours ago. seems like moving 200k
mailboxes between backends really speed it up.
I have my corrupted mailboxes.db and I can send it to anyone
interested in taking a look.
how about a url
Derrick J Brashear wrote:
On Thu, 31 Mar 2005, João Assad wrote:
My db just got corrupted again 2 hours ago. seems like moving 200k
mailboxes between backends really speed it up.
I have my corrupted mailboxes.db and I can send it to anyone
interested in taking a look.
I needed to restart cyrus
cyrus/mupdate[12614]: IOERROR: mapping /var/lib/imap/mailboxes.db file:
Cannot allocate memory
cyrus/mupdate[12614]: failed to mmap /var/lib/imap/mailboxes.db file
cyrus/master[12580]: service mupdate pid 12614 in READY state:
terminated abnormally
Henrique de Moraes Holschuh wrote:
Derrick J Brashear wrote:
On Tue, 29 Mar 2005, João Assad wrote:
Come on guys, someone must have at least an idea I can try.
Anything will help, maybe Im missing something obvious.
Well, you have skiplist corruption, but there's not really anything in
your report which is helpful at suggesting
, but that takes hours. I came up with a
faster
solution wich is to configure a dummy backend on the same server the cyrus
frontend/master instance runs which reduces the import time by hours. Any
sujestions on this matter would also be appreciated.
Thank you very much,
João Assad
João Assad wrote:
Hello everyone,
We use cyrus-imapd-murder as the solution for our website
messaging/e-mail service .
We currently have 1.240.088 users split in 3 backend servers using 1
frontend / master server
(both services running on the same server) for a grand total of
3.479.526
43 matches
Mail list logo
