(ОС: вариант Debian.)
Имея процесс со статусом зомби. PPidПринадлежал к gvimпроцессу. Содержимое /proc/[pid]/wchanявляетсяdo_exit,
/commесть shи /cmdlineпусто, /statusпоказано ниже.
Может ли это быть ошибкой в gvim? Из статьи в ВикипедииПроцесс зомбиЯ читал, что программа может добровольно отказаться от вызова, waitно это было для
gvimсеанса, который был бездействующим в течение довольно долгого времени. Я закрыл процесс gvim– но зомби все еще таится поблизости. Может ли это указывать на ошибку ОС?
Опять же из Википедии:
Если родительская программа больше не запущена, зомби-процессы обычно указывают на ошибку в операционной системе.
И как часто initreap оставил процессы? Прошло не менее 60 минут с момента gvimкончины , но он все еще там.
С другой стороны, может ли быть shи нет gvim?
The/status файлсостояния SigQнуля.
$ less /proc/30339/status
Name : sh
State : Z (zombie)
Tgid : 30339
Pid : 30339
PPid : 29673
TracerPid: 0
Uid : 1000 1000 1000 1000
Gid : 1000 1000 1000 1000
FDSize : 0
Groups : 4 7 20 24 27 29 30 46 107 124 127 1000
Threads : 1
SigQ : 0/30658
SigPnd : 0000000000000000
ShdPnd : 0000000000000000
SigBlk : 0000000000000000
SigIgn : 0000000000003001
SigCgt : 0000000000010002
CapInh : 0000000000000000
CapPrm : 0000000000000000
CapEff : 0000000000000000
CapBnd : ffffffffffffffff
Cpus_allowed : 3
Cpus_allowed_list: 0-1
Mems_allowed : 1
Mems_allowed_list: 0
voluntary_ctxt_switches : 2
nonvoluntary_ctxt_switches: 3
Не то чтобы это нарушало мой сон, но вот интересно…
решение1
Появление зомби, как правило, указывает на ошибку в процессе, который их породил: этот процесс должен уничтожить зомби (вызвав wait) или явно проигнорировать SIGCLD(или установить SA_NOCLDWAITфлаг).
Однако это незначительная ошибка. Процессы-зомби потребляют только запись в таблице процессов, что является незначительным объемом ресурсов. Проблема становится существенной только в том случае, если процесс оставляет после себя тысячи зомби.
Вы не убили родительский процесс зомби: иначе зомби бы исчез. Процесс 29673 (родитель зомби) все еще жив и здоров (но не waiting). Либо это не Gvim, а какой-то его подпроцесс, либо вы закрыли окно Gvim, но программа все еще работает. Запустите, ps l 29673чтобы узнать, что это за процесс.
решение2
Если вы постоянно сталкиваетесь с процессом-зомби, я склонен думать, что определенно что-то не так. Процессы-зомби случаются. Обычно я вижу несколько в месяц на различных системах, которые я обслуживаю как на работе, так и дома.
Обычно их можно объяснить ошибкой оператора или проблемой с определенным программным обеспечением. Перезагрузка обычно решает их, и они обычно не повторяются в течение некоторого времени.
Если они вас беспокоят, вы можете попробовать подключиться к идентификатору их родительского процесса (PPID), gdbчтобы узнать, что происходит, или даже попытаться завершить их:
$ gdb -p 100
(gdb) call waitpid(200, 0, 0)
(gdb) quit
Если вы готовы, я бы рекомендовал вам ознакомиться с дополнительными ресурсами, представленными ниже, чтобы узнать о других методах борьбы с ними.
Рекомендации
решение3
Это происходит каждый раз, когда вы используете gvim? Работает ли gvim, кроме как оставляет зомби после выхода? Если это не вызывает реальных проблем, я бы просто проигнорировал это — зомби не нагружают системные ресурсы. Я бы не удивился, если бы это была ошибка в gvim — или, возможно, в gtk, но если программа вообще не работает, я бы проигнорировал это.
Процесс зомби/умерший обычно происходит, когда дочерний процесс завершается до того, как родительский процесс начинает его прослушивать. Дочерний процесс "остается", потому что не было программы, которая могла бы получить его статус выхода, даже если он успешно завершился - поэтому он становится зомби. Другая причина, по которой вы получаете зомби, может заключаться в том, что большое дерево процессов рушится - возможно, потому что кто-то пытался завершить один или несколько процессов в дереве.
Зомби — это на самом деле способ для ОС сохранить статус выхода и другую информацию о процессе, который не был завершен достаточно корректно, на случай, если кому-то интересно. Помимо записи в таблице процессов, зомби не занимает никаких ресурсов (т. е. памяти или процессора).
IMHO WikiPedia ошибается — или, по крайней мере, ее легко неправильно понять, — когда утверждает, что неубранные зомби означают ошибку ОС, если они задерживаются после того, как основной процесс, который он породил, завершается. Нередко зомби выживает после своих родителей, в этом случае он усыновляется init(PID 1). initможет в конечном итоге пожать его, но некоторые зомби — даже те, которые усыновлены init — вполне могут оставаться до перезагрузки. Пока у вас не так много зомби, что они заполняют таблицу процессов, они вряд ли представляют собой проблему.
Конечно, зомби часто означают, что что-то не так - программа порождает дочернюю, которая умирает до того, как ожидает родительская - но проблема не обязательно в ОС. Конечно, причиной могут быть компоненты ОС - например, отсутствующий или неправильно настроенный звуковой сервер заставляет дочерние процессы, которые должны обрабатывать звук для программы, немедленно завершаться, таким образом оставаясь в виде зомби.
решение4
Как всегда - смотря по обстоятельствам. Большинство инструментов мониторинга становятся желтыми или красными, если они обнаруживают больше определенного количества зомби-процессов.
Так что в принципе да, это обычно признак проблемы.
Но я видел программы, которые порождали зомби-процессы как часть своих "нормальных" операций. Эти зомби-процессы исчезали, когда соответствующий top-level-api (я не говорю родительский процесс здесь) вызывался командой "quit/exit".
Так что в этих случаях, похоже, приложение позаботилось (и, возможно, нуждалось) об этих зомби. Поэтому для мониторинга мне пришлось определить исключение на серверах, где эти приложения были запущены.
В других случаях зомби исчезали через короткое время, поэтому у вас могут быть определенные непостоянные состояния системы с зомби-процессами.
В вашем случае: если gvimвсе сделано, то зомби не должно остаться — так что, вероятно, это ошибка.