Quelle est la cause de ces process imapd qui s'écrouvent?

Nous avons un server de messagerie Mac OS X 10.5 Leopard Server qui a récemment commencé à avoir des problèmes avec les boîtes aux lettres IMAP ayant «format [s] invalide» ce week-end. Il s'est avéré qu'il y avait un mauvais bloc count sur le volume de données IMAP résidentielles et que le problème n'a pas refait surface après la réparation du volume et des boîtes aux lettres affligées. Cependant, un nouveau problème qui persiste est fréquemment en panne de process et les db4 croissantes de db4 "lockers" comme les suivantes:

 Apr 13 17:01:12 host lmtpunix[31509]: DBERROR db4: 1134 lockers 

Les erreurs pour les process imaps de /var/log/system.log sont les suivantes:

 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 

Et ce qui suit dans /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 

Les rapports d'incident sont tous comme les suivants:

 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 

Oui, tous s'écrasent dans process_records dans mailbox_expunge .

Je ne vois pas vraiment d'autres erreurs dans les journaux, au less cela semble être lié aux process écrasés de quelque manière que ce soit ou sont inoffensifs comme SQUAT failed to open index file et IOERROR: fstating sieve script /usr/sieve/u/user/defaultbc: No such file or directory .

Je dois avouer, je n'ai pas encore reconstruit la boîte aux lettres Other Users/listmaster ni la user3 aux lettres user3 . Ce n'est pas toujours le même user.

Nous avons certains users qui ont constaté que le courrier électronique envoyé n'est pas enregistré dans leur boîte aux lettres «Messages envoyés» et n'a pas été depuis la date du problème d'origine. La reconstruction de leur boîte aux lettres (actuellement en utilisant sudo mailbfr -m username d' sudo mailbfr -m username car il sudo mailbfr -m username des permissions supplémentaires fixées en plus de l' sudo /usr/bin/cyrus/bin/reconstruct -r user/username que je lancerais normalement) semble permettre l'envoi nouvellement envoyé mail pour y être enregistré, mais j'ai du mal à find une corrélation entre ce problème et celui-ci (ou toute autre erreur dans les journaux).

Toutes les suggestions seraient grandement appréciées. Est-ce que c'est vraiment écrasant essayer de supprimer des messages? Dois-je simplement rebuild les boîtes aux lettres de tous les users individuellement? Je ne veux vraiment pas rebuild la database Cyrus dans son intégralité et perdre tout statut signalé / lu pour tous les messages.

Je crois que les blocs corrompus sont passés à des index db incorrects qui causent des collisions lors du stockage de nouveldatatables. À l'exception de la database de reconstruction, il n'y a pas beaucoup que vous pouvez faire. Vous pouvez sauvegarder les users. Chercher des files et essayer de les utiliser, mais testez cette idée sur l'user de test. Honnêtement, je pense que harrdrive avec de mauvais blocs devrait être supprimé du server dès que possible de toute façon

J'ai résolu cette question depuis longtime.

Je ne me souviens pas des commands exactes, mais j'ai trouvé un moyen de corréler raisonnablement un crash spécifique à un user spécifique, auquel je pourrais alors exécuter mailbfr -m pour rebuild la boîte aux lettres de cet user. Finalement, j'ai pu rebuild toutes les boîtes aux lettres problème et débarrasser le server du problème.