Недавно у моего 9-летнего файлового сервера Apple G4 произошел случайный сбой. Часто это паника ядра, но иногда система просто зависает. Кажется, что это почти всегда происходит, когда меня нет в офисе ... но даже когда я нахожусь в своем офисе, система находится в отдельной серверной комнате, и почти никогда никого нет за консолью. Подозревая плохую оперативную память, я запустил memtest, но после 20 проходов не обнаружил никаких проблем. (Я выполнил 10 проходов, перезагрузился и еще 10 раз. Оба раза однопользовательский режим). Apple Hardware Test также сообщает об отсутствии проблем (после повторного выполнения более 100 циклов)
Я подозреваю, что оборудование просто выходит из строя ... это является 9 лет все-таки. Но у нас нет бюджета на замену сервера на данный момент. Какие варианты мне подойдут до следующего обновления? Есть ли способ устранить сбой? Или, по крайней мере, каким-либо способом автоматически перезагрузить систему после паники ядра или блокировки, чтобы она могла возобновить обслуживание?
panic.log показывает:
Mon Jun 29 12:52:23 2009
panic(cpu 1 caller 0x00040180): zalloc: "socket" (751876 elements) retry fail 3
Latest stack backtrace for cpu 1:
Backtrace:
0x000954F8 0x00095A10 0x00026898 0x00040180 0x0026B868 0x00290E10 0x00290F1C 0x00296B40
0x002ABDB8 0x000ABD30 0x00000000
Proceeding back via exception chain:
Exception state (sv=0x32288780)
PC=0x9001B08C; MSR=0x0000F030; DAR=0x12555000; DSISR=0x42000000; LR=0x8EF88A00; R1=0xBFFFF700; XCP=0x0000003
0 (0xC00 - System call)
Kernel version:
Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC
*********
Fri Jul 3 10:15:24 2009
panic(cpu 1 caller 0x00040180): zalloc: "socket" (762004 elements) retry fail 3
Latest stack backtrace for cpu 1:
Backtrace:
0x000954F8 0x00095A10 0x00026898 0x00040180 0x0026B868 0x00290E10 0x00290F1C 0x00296B40
0x002ABDB8 0x000ABD30 0x00000000
Proceeding back via exception chain:
Exception state (sv=0x2C543000)
PC=0x9001B08C; MSR=0x0000F030; DAR=0x11A41000; DSISR=0x42000000; LR=0x8EF88A00; R1=0xBFFFF700; XCP=0x0000003
0 (0xC00 - System call)
Kernel version:
Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC
*********
Tue Jul 21 20:44:47 2009
panic(cpu 1 caller 0x00040180): zalloc: "socket" (762004 elements) retry fail 3
Latest stack backtrace for cpu 1:
Backtrace:
0x000954F8 0x00095A10 0x00026898 0x00040180 0x0026B868 0x00290E10 0x00290F1C 0x00296B40
0x002ABDB8 0x000ABD30 0x00000000
Proceeding back via exception chain:
Exception state (sv=0x2C543000)
PC=0x9001B08C; MSR=0x0000F030; DAR=0x11A41000; DSISR=0x42000000; LR=0x8EF88A00; R1=0xBFFFF700; XCP=0x0000003
0 (0xC00 - System call)
Kernel version:
Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC
*********
Я предполагаю, что если он работает как файловый сервер, он работает под управлением Mac OS X Server, верно? Если он не перезагружается автоматически после паники ядра, значит, ваше оборудование достаточно старое и, вероятно, не поддерживается для этого, поскольку оно установлено по умолчанию на сервере.
Очевидно, что сервер не будет пытаться перезагрузиться, если это не паника ядра и он просто завис, но я обнаружил Начало работы по сложным схемам! быть отличным решением этой проблемы. По сути, их программное обеспечение время от времени проверяет свое оборудование в проходном канале питания, и если блок блокируется и перестает проверять связь, он отключает питание. Престо! Автоматическая перезагрузка, паника ядра или нет!
Вы знаете, что вызывает панику ядра? В каком конкретном расширении ядра компьютер дает сбой?
Я написал немного о том, как читать журнал паники ядра по несвязанному вопросу на Суперпользователь в надежде, что это поможет:
Если это не пакет, вы можете узнать имя kext из паники ядра: вы можете найти эту информацию на
~/Library/Logs/panic.logили при перезагрузке компьютера после паники он спросит, хотите ли вы сообщить об ошибке в Apple. Нажмите Отчет, а затем щелкните центральную вкладку, чтобы увидеть подробности сбоя.Примером может быть:
panic(cpu 0 caller 0x0035C330): freeing free mbuf Backtrace, Format - Frame : Return Address (4 potential args on stack) 0x2545bc08 : 0x128d08 (0x3c9afc 0x2545bc2c 0x131de5 0x0) 0x2545bc48 : 0x35c330 (0x3ea258 0x3ae65000 0x23935100 0x493e0) 0x2545bc88 : 0x7424a4 (0x36f19300 0x493e0 0x0 0x134b11) 0x2545bca8 : 0x9f1458 (0x23935000 0x36f19300 0x0 0x0) 0x2545bcd8 : 0x9ef6d6 (0x23935000 0x36f19300 0x0 0x0) 0x2545bcf8 : 0x9fa0ce (0x23935000 0x36f15f00 0x1000000 0x0) 0x2545bea8 : 0x9f375a (0x23935000 0x3a14880 0x40000000 0x34fb8b) 0x2545bf08 : 0x398f79 (0x23935000 0x3a14880 0x1 0x13becf) 0x2545bf58 : 0x39814b (0x3a14880 0x4121d48 0x4121d8c 0x0) 0x2545bf88 : 0x397e81 (0x3a184c0 0x5d3734 0x452084 0x40431f4) 0x2545bfc8 : 0x19a77c (0x3a184c0 0x0 0x19d0b5 0x696543c) Backtrace terminated-invalid frame pointer 0x0
Kernel loadable modules in backtrace (with dependencies):
com.apple.iokit.AppleYukon(1.0.9b3)@0x9ed000
dependency: com.apple.iokit.IONetworkingFamily(1.5.1)@0x73b000
dependency: com.apple.iokit.IOPCIFamily(2.2)@0x60a000
dependency: com.apple.iokit.IOACPIFamily(1.2.0)@0x6b6000
com.apple.iokit.IONetworkingFamily(1.5.1)@0x73b000
Kernel version:
Darwin Kernel Version 8.8.2: Thu Sep 28 20:43:26 PDT 2006; root:xnu-792.14.14.obj~1/RELEASE_I386
Я разделил относительные линии. В частности, вы ищете первую строку после «Загружаемые модули ядра ...». В этом случае товар com.apple.iokit.AppleYukon (который является расширением драйвера / ядра Ethernet), поэтому имя файла будет com.apple.iokit.AppleYukon.kext.
Я предполагаю, что вы уже просмотрели CrashReporter и другие системные журналы, чтобы увидеть, есть ли там что-нибудь интересное.
Но когда я пытаюсь выжать немного лишнего времени из старых машин, первое, что я делаю, это проверяю охлаждение - вытаскиваю всю пыль из коробки, а затем проверяю, хорошо ли вращаются вентиляторы.
... и если вы используете клиент и принимаете предложение Морганта о включении и выключении питания, посмотрите в «Энергосбережение -> Параметры» на предмет «Автоматический перезапуск после сбоя питания». Здесь также вы найдете параметр «Перезапускать автоматически, если сервер« зависает »», если вы используете OS X Server.
На вашем сервере вы можете запустить last команда, чтобы увидеть, когда он загрузился (а также при обычном перезапуске). Есть ли что-нибудь интересное в системных журналах, что происходит примерно в это время?
Также, будучи файловым сервером, обязательно проверяйте жесткие диски. У нас есть G5 (?), Подключенный к RAID, и он не работает правильно, когда RAID не работает.
Также обратите внимание на память, повреждение или другие сбои памяти, которые вполне могут вызвать такого рода случайные вещи.
Если вы можете заменить модули DIMM на ПК x86, попробуйте использовать MemTest x86 +, чтобы увидеть, есть ли какие-либо очевидные ошибки, хотя MemTest может показать чистоту, если ошибки случайные или достаточно неясные.