On Wed, Jan 25, 2006 at 04:06:10PM -0600, Jamie wrote:
> open("./courierimapuiddb", O_RDONLY) = 5
> fstat64(5, 0xFFBEA3F0) = 0
> brk(0x00071E30) = 0
> brk(0x00073E30) = 0
> ioctl(5, TCGETA, 0xFFBEA37C) Err#25 ENOTTY
> read(5, " 1 1 1 3 7 4 4 8 7 5 2".., 8192) = 1064
> read(5, 0x000702DC, 8192) = 0
> llseek(5, 0, SEEK_CUR) = 1064
> close(5) = 0
> open("./tmp/1138220285.M848123P22998_imapuid_0.solarcell",
> O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
> Incurred fault #6, FLTBOUNDS %pc = 0x0001EA00
> siginfo: SIGSEGV SEGV_MAPERR addr=0x00000004
> Received signal #11, SIGSEGV [default]
> siginfo: SIGSEGV SEGV_MAPERR addr=0x00000004
> *** process killed ***
That's a crash. If this happens consistently for a particular account, then
I'd guess it's some sort of software bug rather than a hardware problem
(google for "sig11 faq" to find out how hardware problems can also cause
this symptom)
> The strange thing is, this is only occuring with random
> accounts...most of the accounts are working. And, if we delete the users
> account and re-create it, it will work fine for a while, but sometimes
> will "break" again in the same way.
Maybe just removing courierimapuiddb would be sufficient to make the account
work again for a while.
> Can anyone offer any suggestions as to where I might go from here?
You need to try and obtain a core dump, which you can analyse with gdb to
find out the exact location of the error.
Note that you can run imapd directly from the command line:
# su - username
$ /path/to/imapd ./Maildir
... you're already logged in; issue IMAP commands
Issuing the same commands as the client should cause the crash.
To find out what commands the client is issuing, you could use tcpdump
filtered against the client's IP address, or set IMAPDEBUGFILE=log.txt which
will log the IMAP commands given by *all* clients in a file 'log.txt' within
each Maildir.
Once you have a core dump, you can analyse using
# gdb -c /path/to/corefile /path/to/imapd
...
gdb> bt
which should give a backtrace to where the problem line is.
It may turn out that the courierimapuiddb file has become corrupted, and the
parsing of this file isn't working when it's in a corrupted state. If so,
the actual underlying problem is to find out how this file becomes corrupted
in the first place - and that may be harder to find.
HTH,
Brian.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Courier-imap mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
