Tried to use real (non-virtual) machines and the i still get the same
problem, my guess it that it has to be a problem in Slackware it self. Might
be time to switch to another distribution.
Milos
On Tue, Jun 8, 2010 at 6:40 PM, Andrew Morgan mor...@orst.edu wrote:
On Tue, 8 Jun 2010, Milos
On Fri, Jun 4, 2010 at 3:55 PM, Dan White dwh...@olp.net wrote:
On 04/06/10 09:35 +0200, Milos Zupancic wrote:
Hi,
I'm trying to set up cyrus murder test environment, i have followed
instructions from http://cyrusimap.web.cmu.edu/imapd/install-murder.html
and some web resources.
When i
On Tue, 8 Jun 2010, Milos Zupancic wrote:
On Fri, Jun 4, 2010 at 3:55 PM, Dan White dwh...@olp.net wrote:
On 04/06/10 09:35 +0200, Milos Zupancic wrote:
Hi,
I'm trying to set up cyrus murder test environment, i have followed
instructions from
Hi,
I'm trying to set up cyrus murder test environment, i have followed
instructions from http://cyrusimap.web.cmu.edu/imapd/install-murder.html
and some web resources.
When i try to start everything up i get the following errors on backend and
frontend servers.
I can connect to frontend with a
2010/6/4 Michael Zanin gira...@nline.net.ua
Milos Zupancic miloszu, wrote/schrieb/писав:
Hi,
I'm trying to set up cyrus murder test environment, i have followed
instructions from http://cyrusimap.web.cmu.edu/imapd/install-murder.html
and some web resources.
When i try to start
Tried all of that, nothing seems to work, and to your question about file
system i'm using ext4 FS.
Also getting this logs in syslog (on both, frontend and backend server):
Jun 4 13:27:59 slack3 master[5605]: process 5940 exited, signaled to death
by 11
Jun 4 13:27:59 slack3 master[5605]:
On 04/06/10 09:35 +0200, Milos Zupancic wrote:
Hi,
I'm trying to set up cyrus murder test environment, i have followed
instructions from http://cyrusimap.web.cmu.edu/imapd/install-murder.html
and some web resources.
When i try to start everything up i get the following errors on backend and
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
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
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
On Mon, 04 Apr 2005, João Assad wrote:
The following options seem to have a direct impact on how fast I run
out of resources (obviously) . The more I increase them, the faster I
get the mmap error.
*mupdate_workers_start
mupdate_workers_minspare
mupdate_workers_maxspare
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,
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
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() call fail, that I
see, before the error
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
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
On Fri, 8 Apr 2005, João Assad wrote:
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 strace output here I've noticed mmaps complaining about
ENOMEM way before the mmap inside map_refresh goes crazy.
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,
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 resource limit play happens for
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
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. (at least i hope so)
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. (at
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
cyrus/mupdate[12614]: IOERROR: mapping /var/lib/imap/mailboxes.db
file: Cannot allocate memory
Resource limited memory, or are you really running out of memory?
Letting processes continue running in the face of an mmap failure
needs to be re-examined I guess.
Hello again.
I've been trying to
On Wed, 6 Apr 2005, João Assad wrote:
cyrus/mupdate[12614]: IOERROR: mapping /var/lib/imap/mailboxes.db file:
Cannot allocate memory
Resource limited memory, or are you really running out of memory?
Letting processes continue running in the face of an mmap failure needs to
be re-examined I
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
Derrick J Brashear wrote:
Well, you have skiplist corruption, but there's not really anything
in your report which is helpful at suggesting why you do, or helping
to reproduce it so (if it is a bug) it can be tracked and killed.
Even posting your corrupted skiplist would be more useful.
Yeah
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 distribution or the same kernel? It
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 for it?
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 for it?
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
On Thu, 31 Mar 2005, João Assad wrote:
cyrus/mupdate[12614]: IOERROR: mapping /var/lib/imap/mailboxes.db file:
Cannot allocate memory
Resource limited memory, or are you really running out of memory?
Letting processes continue running in the face of an mmap failure needs to
be re-examined I
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:
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 why you do, or helping to
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
Well, you have skiplist corruption, but there's
not really anything in your report which is
helpful at suggesting why you do, or helping to
reproduce it so (if it is a bug) it can be
tracked and killed.
Even posting your corrupted skiplist would be
more useful.
Yeah I know the info I gave
Come on guys, someone must have at least an idea I can try.
Anything will help, maybe Im missing something obvious.
a repost of the problem below, a bit more elaborated.
We use cyrus-imapd-murder as the solution for our website messaging/e-mail
service meaning all our users have an e-mail
43 matches
Mail list logo
