PID 1 на минималках: свой init, который жмёт зомби

Привет, Хабр! Сегодня расскажу о довольно узком, но довольно интересном моменты работы с Linux — о процессе с PID 1 и зомби-процессах. Когда запускаешь приложение в минимальном окружении и оно оказывается первым процессом, могут возникнуть небольшие сюрпрзики. Та же команда ps может показывать несколько процессов со статусом <defunct> . Эти дефекты и есть зомби-процессы. Столкнувшись с ними впервые, можно растеряться, ведь процесс уже завершился, а запись о нём всё торчит в таблице процессов. Как так, и главное, что с этим делать? Давайте смотреть, почему появляются зомби, какую роль здесь играет процесс №1 (он же init), и как написать свой минималистичный init, который этих зомби убивает (то есть убирает) автоматически. Разобраться, как работает PID 1

https://habr.com/ru/companies/otus/articles/961858/

#linux #PID_1 #init_процесс #zombi_процесс #зомбипроцессы_Linux #waitpid #SIGCHLD #docker_контейнер

PID 1 на минималках: свой init, который жмёт зомби

Привет, Хабр! Сегодня расскажу о довольно узком, но довольно интересном моменты работы с Linux, о процессе с PID 1 и зомби‑процессах. Когда запускаешь приложение...

Хабр

Ok, I forgot about restoring the previous state, cause I already broke this when implementing the generic signal handling via flags. And restoring everything to default must be good enough. Then, using #kqueue was kind of easy. Just this one weirdness that I'm not allowed to ignore #SIGCHLD, so I have to block this instead ... anyone has any idea why?

Still thinking whether I should also add support for #signalfd ... unfortunately different semantics, for that I should (according to its manpage) *block* signals, not ignore them. But maybe I should do some tests there as well.