У нас есть почтовый сервер Mac OS X 10.5 Leopard Server, который недавно в эти выходные начал получать проблемы с почтовыми ящиками IMAP, имеющими "недопустимый формат [ы]". Выяснилось, что на томе, содержащем данные IMAP, было некоторое количество плохих блоков, и проблема не возникла повторно после восстановления тома и поврежденных почтовых ящиков. Однако новая проблема, которая сохраняется, часто дает сбой. imaps процессы и постоянно увеличивающиеся db4 "шкафчики" ошибки, подобные следующим:
Apr 13 17:01:12 host lmtpunix[31509]: DBERROR db4: 1134 lockers
Ошибки при сбое imaps процессы из /var/log/system.log являются следующими:
Apr 12 13:43:10 host imaps[11792]: starttls: TLSv1 with cipher AES128-SHA (128/128 bits new) no authentication
Apr 12 13:43:12 host imaps[11792]: starttls: TLSv1 with cipher AES128-SHA (128/128 bits new) no authentication
Apr 12 13:43:13 host imaps[11792]: login: pool-72-92-XXX-XXX.burl.east.myfairpoint.net [72.92.XXX.XXX] user3 CRAM-MD5+TLS User logged in
Apr 12 13:43:15 host ReportCrash[14362]: Formulating crash report for process imapd[11792]
Apr 12 13:43:15 host master[94896]: process 11792 exited, signaled to death by 11
Apr 12 13:43:15 host ReportCrash[14362]: Saved crashreport to /Library/Logs/CrashReporter/imapd_2011-04-12-134315_host.crash using uid: 0 gid: 0, euid: 0 egid: 0
И следующее из /var/log/mailaccess.log:
Apr 12 13:43:10 host imaps[11792]: accepted connection
Apr 12 13:43:10 host imaps[11792]: mydelete: starting txn 2147495107
Apr 12 13:43:10 host imaps[11792]: mydelete: committing txn 2147495107
Apr 12 13:43:10 host imaps[11792]: mystore: starting txn 2147495108
Apr 12 13:43:10 host imaps[11792]: mystore: committing txn 2147495108
Apr 12 13:43:10 host imaps[11792]: starttls: TLSv1 with cipher AES128-SHA (128/128 bits new) no authentication
Apr 12 13:43:12 host imaps[11792]: accepted connection
Apr 12 13:43:12 host imaps[11792]: mydelete: starting txn 2147495112
Apr 12 13:43:12 host imaps[11792]: mydelete: committing txn 2147495112
Apr 12 13:43:12 host imaps[11792]: mystore: starting txn 2147495113
Apr 12 13:43:12 host imaps[11792]: mystore: committing txn 2147495113
Apr 12 13:43:12 host imaps[11792]: starttls: TLSv1 with cipher AES128-SHA (128/128 bits new) no authentication
Apr 12 13:43:12 host imaps[11792]: AOD: user options: no lookup required for: user3
Apr 12 13:43:13 host imaps[11792]: login: pool-72-92-XXX-XXX.burl.east.myfairpoint.net [72.92.149.161] user3 CRAM-MD5+TLS User logged in
Apr 12 13:43:13 host imaps[11792]: quota set to "unlimited" for mailbox user.user3
Apr 12 13:43:13 host imaps[11792]: open: user user3 opened Other Users/listmaster
Apr 12 13:43:15 host master[94896]: process 11792 exited, signaled to death by 11
Apr 12 13:43:15 host master[94896]: service imaps pid 11792 in BUSY state: terminated abnormally
Apr 12 13:43:15 host master[94896]: process 11792 exited, signaled to death by 11
Apr 12 13:43:15 host master[94896]: service imaps pid 11792 in BUSY state: terminated abnormally
Все отчеты о сбоях выглядят следующим образом:
Process: imapd [39069]
Path: /usr/bin/cyrus/bin/imapd
Identifier: imapd
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: master [38605]
Date/Time: 2011-04-13 18:25:24.068 -0400
OS Version: Mac OS X Server 10.5.7 (9J61)
Report Version: 6
Anonymous UUID: 223C4DD1-2AE2-4381-8A28-DEB9082281A8
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000077a0ca64
Crashed Thread: 0
Thread 0 Crashed:
0 imapd 0x0003090c process_records + 588
1 imapd 0x00031362 mailbox_expunge + 2146
2 imapd 0x00006fde cmd_close + 179
3 imapd 0x00018cf8 cmdloop + 2940
4 imapd 0x0001c1b7 service_main + 1498
5 imapd 0x00002e73 main + 3502
6 imapd 0x00002006 start + 54
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x61766970 ebx: 0x000306cb ecx: 0x00000008 edx: 0x77a0ca64
edi: 0x00bfffa4 esi: 0x162a5fa4 ebp: 0xbfffad48 esp: 0xbfffac90
ss: 0x0000001f efl: 0x00010202 eip: 0x0003090c cs: 0x00000017
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037
cr2: 0x77a0ca64
Да, они все врезаются process_records в mailbox_expunge.
На самом деле я не вижу никаких других ошибок в журналах, по крайней мере, которые кажутся так или иначе связаны с сбойными процессами или безобидны, например SQUAT failed to open index file и IOERROR: fstating sieve script /usr/sieve/u/user/defaultbc: No such file or directory.
Должен признать, я не перестраивал Other Users/listmaster почтовый ящик, ни user3 почтового ящика пока нет. Это не всегда один и тот же пользователь.
У нас есть некоторые пользователи, которые обнаружили, что отправленное электронное письмо не сохраняется в их почтовом ящике «Отправленные сообщения» и не сохранялось с даты первоначальной проблемы. Восстановление их почтового ящика (в настоящее время используется sudo mailbfr -m username поскольку он делает некоторые дополнительные разрешения, исправленные в дополнение к sudo /usr/bin/cyrus/bin/reconstruct -r user/username который я обычно запускал), похоже, позволяет сохранять в нем вновь отправленное электронное письмо, но мне не удается найти корреляцию между этой проблемой и этой (или любыми другими ошибками в журналах).
Любые предложения будут ценны. Действительно ли происходит сбой при попытке удалить сообщения? Должен ли я просто перестраивать почтовые ящики всех пользователей по отдельности? я действительно не хотят полностью перестраивать базу данных Cyrus и терять все помеченные / прочитанные статусы для всех сообщений.
Я давно решил эту проблему.
Я не помню точных команд, но я нашел способ разумно соотнести конкретный сбой с конкретным пользователем, после чего я мог бы запустить mailbfr -m для восстановления почтового ящика этого пользователя. В конце концов я смог восстановить все проблемные почтовые ящики и избавить сервер от проблемы.
Я считаю, что поврежденные блоки попали в неправильные индексы db, которые вызывают сбои при хранении новых данных. Кроме восстановления базы данных, вы мало что можете сделать. Вы можете создавать резервные копии файлов .seen пользователей и попробовать их использовать, но протестируйте эту идею на тестовом пользователе. Честно говоря, думаю, что харрдрайв с плохими блоками в любом случае нужно убрать с сервера как можно скорее.