Pull to refresh

Comments 20

UFO landed and left these words here
Спасибо! Складываю каждую часть в dropbox =)
Полезность такого мануала сомнительна…

Основы ведь и так есть в хендбуке, а тонкости всё равно всё забудутся, и придётся каждый раз подсматривать, пока не наступит просветление. А для этих целей лучше какой-нибудь небольшой cheatsheet подойдёт…

Вы про какой хэндбук?
Gentoo handbook — он такой один.
А вы его сами то видели? Ну и покажите мне где там хоть намек на материал описанный тут?
тонкостей тут вроде нету, но их всегда можно узнать в мане, главное — основы, а они как раз в статье и описаны
Полезность Вашего коммента сомнительна…

Я давно с Linux и некоторые вещи для меня тут оказались полезны. Если это для Вас очевидно — это еще не значит что все это знают.

За --forest и renice спасибо.
Пост отличный, разждевано так, что просто глотай.
Ждём продолжения!
добавлю крупицу инфы.
Существует понятие — zombie-process. Это процесс порожденный другим процессом, и уже остановленный. Все что в нем сохранилось — лишь информация о коде возврата, и еще несколько системных значений. Система будет хранить зомби-процесс до тех пор пока родительский процесс не вызовет wait() или же пока сам родитель не завершится.

Классической ошибкой программиста будет в данном случае создание процессов exec() без последующего вызова wait()- так как в этом случае ваше приложение будет постоянно плодить новых и новых зомби.
Решением проблемы станет вызов wait/waitpid или же использование сигнала:
signal(SIGCLD, SIG_IGN);
этот код, вызванный до создания новых процессов, приведет к автоматическому удалению зомби ( и если вам не нужно считывать информацию о завершившихся порожденных процессах — это будет самое простое решение ).
а как получить список зомби?
ps aux | grep program_name
процессы с флагом Z+ и будут зомби
статус процесса.
например если статус = D (Uninterruptible sleep) — его не убьешь, пока он не выйдет из такого состояния. а если процесс надолго завис в такое статусе это очень неприятно, возможно проблемы с дисковыми устройствами.
Разве init не наследует зомби с целью получить их код? ИМХО вы цитируете какую-то древнюю книжку по юниксам; я ни разу не видел «орд зомби» под линуксом, какие бы неприличности там не творились.

А уж сколько forc'ов я лично делал без получения кода… И никаких проблем.
насчет древней книжки не знаю, у меня такое случилось буквально вчера на живом примере, когда после проги осталось 200 зомбей, процессов которые она вызывала через fork() exec() и без последующего wait(). Вылечилось как написал выше.
может дело в том что ваша программа завершалась после всех «безобразий» а моя работала долго, и все зомби естественно жили только пока она была жива.
А, понял. Речь про долго работающие программы. Да, init наследует зомби после смерти родителя. Если родитель долго работает, будут зомби.

PS Кстати, а почему init? pid=0 — это swapper. Странная логика…
Что такое «остановленный процесс»? Ему просто не выделяется процессорное время?
Именно. В виндах такого понятия нет, так что мигрирующим приходится долго осознавать такую простую вещь — программу можно «остановить», а потом «продолжить». Очень удобно, если есть какие-то подозрения относительно программы. Остановил, изучил, продолжил.
Есть еще pstree, но он отображает значительно меньше информации.

pstree -p — отобразить дерево процессов с принадлежащими pid;
pstree -u — отобразить дерево процессов с принадлежащими uid;
pstree -pu — отобразить дерево процессов с pid и uid.
Only those users with full accounts are able to leave comments. Log in, please.