Linux: Процессы

[opensophy]

Обновление от 28 июля 2026 года.

Статья была обновлена под редакционную политику opensophy.

Читать обновлённую статью.

• Все последующие обновления материала будут публиковаться только на сайте.

[Granulex]

Статья сама предупреждает про «чувствительные данные» в env-переменных – но не договаривает: они затем лежат в /proc/PID/environ и читаются любым процессом с нужными правами. Docker по умолчанию это и делает.

[opensophy]

Здравствуйте! Согласен, это хороший нюанс. В статье я только кратко упомянул, что в env могут лежать чувствительные данные, но не стал углубляться в вопросы доступа через /proc и особенности контейнерных окружений, счёл эту информацию на другую часть статьи по безопасности Linux.

[simple__mortal]

Обожаю линуксовые учебники, гайды, мануалы вот за такое

# Найти зомби
# Найти родителя зомби и «напомнить» ему убраться
# Если родитель мёртво завис – убить его (дети усыновятся systemd)

[dlinyj]

На счёт зомби, на сколько я сейчас знаю, такое явление очень редкое. Даже преднамеренно сложно сделать зомби. Или я где-то ошибаюсь?

[opensophy]

Здравствуйте! Тут многое зависит от контекста использования системы. В типичном администрировании — да, зомби явление +/- редкое. А вот если тестировать сторонние инструменты какие-нибудь, то могу из личного опыта сказать: проверял несколько инструментов на базе Puppeteer, 2 из 5 оказались с багом в управлении дочерними процессами и стабильно плодили зомби(не прям много но всё же.)

[dlinyj]

Администрированием никогда не занимался, поэтому не знаю. Но как программист, помню что специально пытался прогу написать, чтобы зомби по старым мануалам, и не это не удалось.

[AlexSky]

Очень просто же.

#include <unistd.h>
#include <stdlib.h>

int main() {
    pid_t pid = fork();

    if (pid == 0)
        _exit(0);
    else
        sleep(300);

    return 0;
}

Запускаем, смотрим дочерний процесс:

$ cat /proc/1313520/status | grep State
State:  Z (zombie)

[dlinyj]

Я бы ещё добавил вывод на экран пидов. Через ps видать будет?

[AlexSky]

Да, я просто ps -A сделал, в конце видно два процесса.

[dellavrite]

Если и упоминать чердак разрабов линукс(/proc), можно было бы и про /sys упомянуть как про более удобную и упорядоченную часть этого чердака.

А так, мне явно не хватило структуры статьи в начале. Из за того что информации довольно много и изначально не было структуры по которой можно следовать и на которую можно наслаивать информацию.

Было бы неплохо в виде съемки или хотя бы содержания статьи

[opensophy]

Здравствуйте! Спасибо за замечание :)

В статье не предусматривал раздел для быстрого перехода по якорному содержанию, поскольку статья также выходит на сайте opensophy, где есть TOC-панель справа. Хабру в копилку идею создать слева меню с TOC-панелью.(думаю это хорошая фича чтобы не писать содержание всё время в тексте)

Про /sys — не стал делать упоминание, поскольку о нём больше и подробнее будет возможно в следующих частях серии по Linux.

[Diaboliko]

Ещё пример: на 8-ядерном сервере привяжите базу данных к ядрам 0-3, а веб-сервер — к 4-7. Это снизит конкуренцию за кэш и память, уменьшит миграцию и повысит стабильность.

Крайне сомнительный пример as is. Нужно прям все условия эксплуатации описать чтобы не было дурного привкуса.. :)

[nuald]

Пару замечаний по памяти (сейчас это больная тема, и даже серьёзные специалисты плавают):

• Замерять реальное потребление памяти лучше с /proc/PID/smaps_rollup (у них RSS тоже есть, но я хочу заметить про PSS). PSS (proportional share size) лучше отражают потребление на уровне системы. Например, если процесс использует shared objects, то их код проецируется (mmap-ed used pages) в память процесса, и это добавляется в RSS. Другой процесс может использовать те же страницы, и это добавится в его RSS, хотя в физической памяти это страницы используются в единственном экземпляре. PSS делит использованные страницы и правильно показывает вклад процесса в потребление всей памяти. RSS удобно для метрик, когда вы планируете узнать пиковое потребление, если, например все библиотеки будут линковаться статически. PSS удобно когда вы рассчитываете потребление всех процессов в системе.

• ulimit имеет принципиальное различие с cgroup касательно ограничений памяти. ulimit ограничивает только виртуальную память, а cgroup - физическую. Для некоторых программ это очень важно. Например, сборщик мусора Go любит себе выделять под гиг виртуальной памяти, а использовать только несколько десятков мегабайт. cgroup будут правильно контролировать такие процессы, а ulimit - нет.

[opensophy]

Спасибо за замечания, оба учёл в обновлении статьи.

Про PSS — добавил объяснение разницы с RSS: почему суммарный RSS завышает реальное потребление при shared libraries, и когда что использовать (RSS для оценки пикового потребления одного процесса, PSS для расчёта потребления по всей системе). Добавил и команду через smaps_rollup.

Про ulimit vs cgroup — добавил явное указание что ulimit ограничивает виртуальную память, а cgroup физическую, с примером Go GC как раз по вашему описанию.

[Paris_Null]

Полезное уточнение про потоки и task_struct — часто в обучающих материалах это обходят стороной, хотя именно флаги CLONE_VM / CLONE_SIGHAND объясняют, почему падение одного потока кладёт весь процесс. Стоит добавить: в контексте сетевых демонов (nginx, sshd) это поведение напрямую влияет на модель изоляции — поэтому nginx использует multi-process вместо multi-thread, чтобы ошибка в worker не затронула master. Планируете в серии отдельный раздел про namespaces и cgroups? Это логичное продолжение темы процессов, особенно для тех, кто разбирает изоляцию контейнеров.

[opensophy]

Спасибо за дополнение! Про nginx и модель изоляции — добавил в статью. Про namespaces и cgroups — да, планирую, это логичное продолжение. cgroups частично затронуты уже в этой части, а namespaces войдут в отдельный раздел серии, ближе к теме контейнеризации либо в серии по Docker.

[opensophy]

Обновление от 28 июля 2026 года.

Статья была обновлена под редакционную политику opensophy.

Читать обновлённую статью.

• Все последующие обновления материала будут публиковаться только на сайте.