Инициализация системы

Привет, %username%! В Linux после загрузки ядра начинается инициализация системы, сервисов и других компонентов. За это отвечает процесс с PID 1, называемый “init proccess” или “процесс инициализации”. Он запускается ядром сразу после завершения загрузки и будет выполняться пока будет работать система.

🔄 Обновлено 2026-05-15: обзорная часть про SysV/systemd/Upstart/Runit/OpenRC валидна. В конце добавил блок «systemd для повседневной работы» — про то, что в systemd за 4-5 лет реально пригодилось админу: systemctl edit (drop-in без редактирования юнитов), systemd-run (запуск разовых задач в нормальном scope), systemd-oomd (userspace-killer вместо OOM ядра), soft-reboot для k8s-нод, journald-utils.

Процесс инициализации запускает все процессы, которые должны быть запущены и является для них родительским процессом. Все процессы, которые запускает процесс инициализации, так же могу порождать дочерние процессы.

А теперь посмотрим на то, какие именно бывают процессы инициализации.

System V#

System V или SysV - это довольно старая система инициализации, которая до сих пор пользуется не малой популярностью. Была основой для создания многих других систем инициализации и разработана еще в 1983 году. Большая часть дистрибутивов Linux изначально использовали SysV.

Основные возможности SysV:

• Написание файлов запуска служб на bash;
• Последовательный запуск служб;
• Сортировка порядка запуска с помощью номеров в именах файлов;
• Команды для запуска, остановки и проверки состояния служб.

Никакой параллельной загрузки, системы зависимостей, запуска по требованию и автоматического запуска здесь не было и в помине. Дополнительно почитать в Wikipedia .

Systemd#

Systemd - это более новая система инициализации. Сейчас используется почти во всех популярных Linux дистрибутивах. systemd это не только инициализирующий процесс с кучей возможностей, но и набор инструментов для управления службами. Основная цель systemd – иметь полный контроль над всеми процессами не только во время их запуска, но и на протяжении всего выполнения.

Systemd сильно отличается от существующих систем инициализации, тем как она работает с сервисами и конфигурационными файлами самих сервисов. Совместимости со скриптами SysV нет, их нужно преобразовать в linux systemd unit файлы.

Вот основные особенности:

• Понятный, простой и эффективный дизайн;
• Поддерживается планирование заданий с помощью таймеров Systemd;
• Поддерживается управление сетью с помощью networkd;
• Для управления DNS используется systemd-resolved;
• Хранение журналов в бинарных файлах;
• Параллельная загрузка служб на основе зависимостей;
• Сохранение состояния сервисов linux systemd для возможного восстановления;
• Улучшенная интеграция с Gnome;
• Запуск сервисов по требованию;
• Поддерживается завершение дополнительных процессов;
• Поддерживается собственный журнал с помощью journald;

Дополнительно почитать в Wikipedia .

Upstart#

Upstart - это система инициализации на основе событий, разработанная в Canonical и призванная заменять SysV. Она может запускать системные службы, выполнять над ними различные задачи, инспектировать их во время выполнения, а также выполнять нужные действия в ответ на события в системе.

Это гибридная система инициализации, она использует как SysV скрипты запуска, так и файлы служб Systemd. Вот ее самые заметные особенности:

• Изначально разработанная для Ubuntu, но может использоваться и в других дистрибутивах;
• Параллельная загрузка сервисов;
• Связь с процессом инициализации через DBus;
• Пользователи могут запускать и останавливать свои процессы;
• Перезапуск служб, которые неожиданно завершились;
• Автоматический перезапуск служб;
• Запуск и остановка служб на основе событий;
• Генерация событий во время запуска и остановки служб;
• События могут быть отправлены обычными процессами;

Большинство ее возможностей работают благодаря интеграции с системой инициализации Systemd. В последнее время всё меньше используются скрипты SysV init и всё больше применяются юнит файлы Systemd.

Дополнительно почитать в Wikipedia .

Runit#

Runit - это кроссплатформенная система инициализации, которая может работать в GNU Linux, Solaris, BSD и MacOS. Это отличная альтернатива для SysV с поддержкой мониторинга состояния служб.

Здесь есть некоторые интересные особенности, которых нет в других системах инициализации:

• Быстрая система загрузки и выключения;
• Портативность;
• Небольшое количество кода системы инициализации.
• Легкое создание файлов конфигурации служб;
• Полный контроль сервисов, каждый сервис привязывается к своему каталогу;
• Надежное средство журналирования и ротации логов;

Дополнительно почитать в Wikipedia .

OpenRC#

OpenRC - это система инициализации Linux и Unix подобных операционных систем совместимая с SysV и поддерживающая систему зависимостей во время запуска. Она приносит некоторые улучшения в SysV, и как и другие системы инициализации Linux, совместима с ней, но вы должны иметь в виду, что OpenRC не заменяет полностью файл /sbin/init. Эта система инициализации используется в Gentoo и дистрибутивах BSD.

Кроме стандартных возможностей SysV, здесь поддерживается также:

• Поддержка параллельного запуска служб;
• Поддерживает настройку в одном отдельном файле;
• По сравнению с SysV тут появилось много новых возможностей, но все еще не все те, что нужны для оптимальной работы системы.
• Работает как демон;
• Поддержка зависимостей служб;

Дополнительно почитать в Wikipedia .

systemd для повседневной работы#

Раз в большинстве систем systemd, давай по верхам пробежимся по штукам, без которых системный администратор в 2026-м точно не должен жить — они почти все появились или стабилизировались как раз за последние 4-5 лет.

systemctl edit — drop-in вместо правки юнита#

Никогда не редактируй /usr/lib/systemd/system/*.service руками — твои правки снесёт при обновлении пакета. Вместо этого:

sudo systemctl edit nginx.service

Откроется редактор с пустым drop-in файлом в /etc/systemd/system/nginx.service.d/override.conf. Кладёшь туда только то, что меняешь — например:

[Service]
LimitNOFILE=65536
Environment="ENV=production"

После выхода из редактора systemd daemon-reload уже не нужен — systemctl edit сам перезагрузит конфиг. А systemctl edit --full откроет копию юнита целиком, если хочется переписать его полностью.

systemd-run — разовый запуск в scope#

Запустить любую команду как полноценный systemd-юнит можно без написания .service-файла:

# фоновый бэкап с лимитами и таймаутом
sudo systemd-run \
    --unit=db-backup \
    --property=MemoryMax=2G \
    --property=CPUQuota=50% \
    --on-active=5min \
    --timer-property=AccuracySec=1us \
    /usr/local/bin/pg_dump_app.sh

# таймер для регулярного запуска прямо из строки
sudo systemd-run --on-calendar="hourly" /usr/local/bin/sync.sh

Это альтернатива at/nohup/tmux/cron для одноразовых задач — с готовыми логами в journald и нормальной изоляцией.

systemd-oomd — userspace OOM-killer#

Ядерный OOM-killer срабатывает поздно и часто прибивает не тот процесс. systemd-oomd (по умолчанию включён в Ubuntu 22.04+ и Fedora) работает в userspace и принимает решения до того, как система упрётся в стенку — через cgroup’ы и метрики PSI (Pressure Stall Information). По дороге пишет в journald, кого и почему придушил:

journalctl -u systemd-oomd.service

Настройка — OOMPolicy=kill|stop|continue в юнитах + /etc/systemd/oomd.conf.

Soft-reboot для горячих обновлений#

systemd 254 (август 2023) принёс soft-reboot — перезагрузку userspace без перезагрузки ядра. Сценарий: обновил все пакеты, надо «начать с чистого PID 1», но даунтайм от полной перезагрузки слишком дорогой:

sudo systemctl soft-reboot

Все процессы userspace убиваются, заново стартует PID 1 со свежим окружением — без ребута ядра, без BIOS/firmware. Особенно полезно для k8s-нод и серверов, у которых boot занимает минуты.

journalctl — каждый день#

Полезные шорткаты:

# логи юнита с момента старта системы
journalctl -u nginx.service -b

# хвост в реальном времени (как tail -f)
journalctl -u nginx.service -f

# только ошибки за последний час
journalctl -p err --since "1 hour ago"

# логи за конкретный boot
journalctl --list-boots
journalctl -b -1   # предыдущий boot

# логи в JSON (для парсинга)
journalctl -o json -u nginx.service

systemd-analyze#

Хочешь узнать, что тормозит загрузку:

systemd-analyze blame              # сортировка юнитов по времени старта
systemd-analyze critical-chain     # критический путь
systemd-analyze security nginx     # security score юнита (NoNewPrivileges, ProtectHome и т.д.)

Последняя команда отдельно полезна — даёт чек-лист, как ужесточить sandbox любого сервиса.

Итоги#

Знать и работать прям со всеми системами инициализации тебе вряд ли придется, но знать об их наличии я считаю надо. В большинстве систем с которыми приходится работать, обычно используется systemd.

На этом всё! Profit!

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат , а так же подписывайся на канал .

О способах отблагодарить автора можно почитать на странице “Донаты ”.