У меня есть сервер с 3 экземплярами Oracle, а файловая система - nfs с netapp. После выключения баз данных один процесс для каждой базы данных долгое время не завершается. Каждое kill -i не работает. Я пробовал связать, запилить команду через ошибку.
И iostat показывает, что сервер netapp выполняет много операций ввода-вывода. Итак, кто-то сказал, что процесс был занят записью данных на удаленный сервер netapp, и до завершения записи он не завершится. Так что нужно было просто подождать, пока все операции ввода-вывода не будут выполнены.
После более длительного ожидания (около 1,5 часов) процессы завершаются.
Итак, мой вопрос: как процесс может игнорировать сигнал уничтожения? Насколько я знаю, если мы убьем -9, он немедленно прекратится. Сталкивались ли вы с такой ситуацией, когда kill -i не убивает процесс сразу?
TEST7-stdby-phxdbnfs11$> ps -ef|grep dbw0 oracle 1469 25053 0 22:36:53 pts/1 0:00 grep dbw0 oracle 26795 1 0 21:55:23 ? 0:00 ora_dbw0_TEST7 oracle 1051 1 0 Apr 08 ? 3958:51 ora_dbw0_TEST2 oracle 471 1 0 Apr 08 ? 6391:43 ora_dbw0_TEST1 TEST7-stdby-phxdbnfs11$> kill -9 1051 TEST7-stdby-phxdbnfs11$> ps -ef|grep dbw0 oracle 1493 25053 0 22:37:07 pts/1 0:00 grep dbw0 oracle 26795 1 0 21:55:23 ? 0:00 ora_dbw0_TEST7 oracle 1051 1 0 Apr 08 ? 3958:51 ora_dbw0_TEST2 oracle 471 1 0 Apr 08 ? 6391:43 ora_dbw0_TEST1 TEST7-stdby-phxdbnfs11$> kill -9 471 TEST7-stdby-phxdbnfs11$> ps -ef|grep dbw0 oracle 26795 1 0 21:55:23 ? 0:00 ora_dbw0_TEST7 oracle 1051 1 0 Apr 08 ? 3958:51 ora_dbw0_TEST2 oracle 471 1 0 Apr 08 ? 6391:43 ora_dbw0_TEST1 oracle 1495 25053 0 22:37:22 pts/1 0:00 grep dbw0 TEST7-stdby-phxdbnfs11$> ps -ef|grep smon oracle 1524 25053 0 22:38:02 pts/1 0:00 grep smon TEST7-stdby-phxdbnfs11$> ps -ef|grep dbw0 oracle 1526 25053 0 22:38:06 pts/1 0:00 grep dbw0 oracle 26795 1 0 21:55:23 ? 0:00 ora_dbw0_TEST7 oracle 1051 1 0 Apr 08 ? 3958:51 ora_dbw0_TEST2 oracle 471 1 0 Apr 08 ? 6391:43 ora_dbw0_TEST1 TEST7-stdby-phxdbnfs11$> kill -9 1051 471 26795 TEST7-stdby-phxdbnfs11$> ps -ef|grep dbw0 oracle 1528 25053 0 22:38:19 pts/1 0:00 grep dbw0 oracle 26795 1 0 21:55:23 ? 0:00 ora_dbw0_TEST7 oracle 1051 1 0 Apr 08 ? 3958:51 ora_dbw0_TEST2 oracle 471 1 0 Apr 08 ? 6391:43 ora_dbw0_TEST1 TEST7-stdby-phxdbnfs11$> truss -p 26795 truss: unanticipated system error: 26795 TEST7-stdby-phxdbnfs11$> pfiles 26795 pfiles: unanticipated system error: 26795
Процесс получит сигнал KILL (все сигналы ведут себя одинаково) только и только тогда, когда он находится в «пользовательском пространстве». Если он находится в пространстве ядра (например, ожидает, пока общий ресурс NFS доставит данные, прочитанные из файла), он не получит сигнал (сигнал будет ждать, пока процесс не вернется в пространство пользователя, он не потеряется).
У большинства NFSD есть несколько вариантов относительно этого, он может вернуться из состояния чтения с ошибкой, если истечет время ожидания. Это приведет к потере данных (как и другой вариант ..), потому что не все программы проверяют все read() полученные результаты.
Процессы не могут игнорировать / отменять сигнал KILL, это только уведомление и дает возможность сохранить любые необходимые данные.
В вопросе не указана клиентская платформа, поэтому я предполагаю Linux.
Видеть соответствующий FAQ на сайте Linux NFS.
Процессы не могут игнорировать SIGKILL, но системные вызовы могут блокировать обработку сигналов.
Есть два флага монтирования для клиентов Linux, которые можно использовать для решения этой проблемы: soft и intr.
soft заставляет NFS в конечном итоге отказываться, когда запрос не выполняется. Если ваше приложение плохо написано для обеспечения устойчивости к сбоям системных вызовов (а многие, многие приложения написаны не так), это может вызвать повреждение данных.
intr пытается сделать системные вызовы NFS более безопасными, чем soft. Тем не менее, все еще возможно получить intr,hard перейти в неубиваемое состояние.