Мы испытываем загадочное зависание при выключении недавно созданного блока Oracle / Sun Solaris 10 SPARC. Это повторяется (в том же месте ... насколько мы можем судить). Мы даем ему возможность поработать несколько раз в течение 5-10 минут, но ничего не вышло.
Я никогда раньше не видел этого.
Последнее, что отображается на консоли, это то, что syslogd был отправлен сигнал 15. Перед нами отключение snmpdx на коробке последней вещью на консоли было то, что snmpdx был отправлен сигнал 15 (после syslogd был отправлен сигнал 15).
Хотя это было очень редко, в прошлые дни Solaris я бы лучше понял из опыта, где может быть проблема, и затем мог бы сузить круг вопросов с помощью глупой (но эффективной) отладки. echo положения в /etc/*.d скрипты. С SMF на картинке, я не совсем уверен, с чего начать.
Мы создали аварийный дамп через sync на {ok} запросите дальнейший анализ, а затем позвольте окну подняться, потому что это рабочий сервер и наше запланированное окно простоя закрывается.
/var/adm/messages ничего полезного не показывает.
Как бы вы отладили эту ситуацию? Есть ли способ перестать скрывать то, что происходит при выключении, чтобы показать, например, все, что делается? (Мне никогда не нравилось, что многое скрывается, начиная с Solaris 10, и во время загрузки)
mdb ps файла savecore показывает, что во время зависания выполнялись следующие процессы (afsd - это клиент OpenAFS, и многие из них ожидаются):
> > ::ps
S PID PPID PGID SID UID FLAGS ADDR NAME
R 0 0 0 0 0 0x00000001 00000000018387c0 sched
R 108 0 0 0 0 0x00020001 00000600110fe010 zpool-silmaril-p
R 3 0 0 0 0 0x00020001 0000060010b29848 fsflush
R 2 0 0 0 0 0x00020001 0000060010b2a468 pageout
R 1 0 0 0 0 0x4a024000 0000060010b2b088 init
R 1327 1 1327 329 0 0x4a024002 00000600176ab0c0 reboot
R 747 1 7 7 0 0x42020001 0000060017f9d0e0 afsd
R 749 1 7 7 0 0x42020001 00000600180104d0 afsd
R 752 1 7 7 0 0x42020001 0000060017cb44b8 afsd
R 754 1 7 7 0 0x42020001 0000060017fc8068 afsd
R 756 1 7 7 0 0x42020001 0000060017fcb0e8 afsd
R 760 1 7 7 0 0x42020001 00000600177f4048 afsd
R 762 1 7 7 0 0x42020001 000006001800f8b0 afsd
R 764 1 7 7 0 0x42020001 000006001800ec90 afsd
R 378 1 378 378 0 0x42020000 0000060013aee480 inetd
R 7 1 7 7 0 0x42020000 0000060010b28008 svc.startd
R 329 7 329 329 0 0x4a024000 00000600110ff850 sh
Z 317 7 317 317 0 0x4a014002 0000060013b3a490 sac
При использовании SMF вы все еще можете использовать старомодные эхо-сигналы в скриптах. Просто зайдите в / lib / svc / method и отредактируйте. Из этого списка процессов я бы сказал, что это связано с AFS, но я этим не пользовался.
/ var / svc / log содержит файлы журналов для всех служб, подпадающих под управление SMF. По крайней мере, это отправная точка для устранения проблем с процессами SMF.
Я согласен с Дэвидом, убедитесь, что с этого сервера нет подключений NFS, которые могут оставаться открытыми, и что этот сервер не монтирует другие файловые системы NFS, которые могут быть недоступны.
Мне сразу приходят в голову две вещи. Во-первых, я использовал NFS, чтобы сделать это, когда клиент заканчивался, а сервер был недоступен.
В качестве альтернативы, при отладке я бы посмотрел на использование -x вариант sh или ksh при запуске, предполагая, что вы все еще можете добраться до скриптов.
Прошло некоторое время, но насколько я помню, если вы загрузите коробку с аргументами ядра -v -m verbose, вы получите сообщения ядра (-v) и сообщения SVCS (-m verbose), отображаемые на консоли. По крайней мере, так вы могли бы лучше понять, что он пытается сделать ...
tail /var/svc/log/rc6.log поможет, если вы выполнили init 6. Однако любой экземпляр проблем с fmd может вызвать его зависание.