Systemd on Lead DevOps

ulimit и systemd LimitNOFILE — почему ulimit -n в unit не живёт

Sat, 19 Sep 2026 00:00:00 +0000

Что такое nofile и где он живёт

nofile — максимальное количество открытых файловых дескрипторов на один процесс. Это не только обычные файлы, а сокеты, pipe, stdin/stdout/stderr, логи через journald — всё считается. Когда nginx или Go-приложение падает с too many open files, дело в этом лимите.

Лимиты живут на трёх уровнях:

Уровень	Где смотреть	Что контролирует
Ядро (системный)	`/proc/sys/fs/file-max`, `/proc/sys/fs/nr_open`	Абсолютный потолок по всей системе
PAM / login	`/etc/security/limits.conf`, `/etc/security/limits.d/`	Для сессий через `pam_limits.so`
systemd	`LimitNOFILE=` в unit, `DefaultLimitNOFILE=` в `system.conf`	Для сервисов, управляемых systemd

Примечание

/proc/sys/fs/nr_open — верхняя граница, до которой можно поднять nofile для одного процесса. По умолчанию обычно 1073741816 (≈1B), но на практике редко нужно больше 1048576.

coredumpctl: найти падение бинаря

Fri, 18 Sep 2026 00:00:00 +0000

Что такое coredumpctl и как он работает

Когда бинарь падает с SEGV, ядро может сохранить core dump — снимок памяти процесса в момент креша. В systemd-based дистрибутивах за сбор, хранение и поиск этих дампов отвечёт coredumpctl, обёртка над systemd-coredump. Он хранит дампы в /var/lib/systemd/coredump/ и индексирует метаданные через journald.

Примечание

Для работы нужен systemd-coredump и включённый journald. В минимальных контейнерах без systemd этот инструмент недоступен.

Docker logs и journald: выбор драйвера логирования

Fri, 18 Sep 2026 00:00:00 +0000

Когда контейнер падает, логи — первое, что нужно увидеть. docker logs выглядит просто, но под капотом работает разные драйверы логирования, и выбор влияет на то, как хранятся, вращаются и доступны логи. Вот что стоит знать перед тем, как доверять дефолту.

Как работает docker logs

Команда docker logs <container> читает поток stdout/stderr контейнера и выдаёт его в терминал. За этим стоит драйвер логирования — компонент, который определяет, куда именно пишутся данные. По умолчанию это json-file: каждый контейнер получает JSON-файл на хосте, в который записываются все строки вывода.

Chrony вместо ntpd

Thu, 17 Sep 2026 00:00:00 +0000

В Debian/Ubuntu и RHEL/CentOS ntpd давно пора менять на chrony. Он быстрее сходится к точному времени, лучше работает при нестабильных сетях и меньше нагружает систему. В современных дистрибутивах chrony уже стоит по умолчанию — но если он ещё не развёрнут, переход занимает минуту.

Установка

На RHEL-подобных:

sudo dnf install chrony -y
sudo systemctl enable --now chronyd

На Debian/Ubuntu:

sudo apt install chrony -y
sudo systemctl enable --now chronyd

Если на машине раньше работал ntpd, остановите и отключите его, чтобы не было конфликта портов:

journalctl: фильтры и follow

Thu, 17 Sep 2026 00:00:00 +0000

Системный журнал systemd — это первое место, куда нужно смотреть, когда сервис упал или узел начал жрать CPU. journalctl умеет гораздо больше, чем вывести весь лог подряд: фильтровать по юнитам, приоритетам, временным окнам и читать в реальном времени. Ниже — рабочий набор, который я использую ежедневно.

Follow in real time

Поведение, аналогичное tail -f, но с учётом структурированного формата journald:

journalctl -f

Флаг -f (short for --follow) выводит новые записи по мере их появления. По умолчанию показывает все юниты — удобно, когда не знаешь, где именно горит.

logrotate для своих демонов

Tue, 08 Sep 2026 00:00:00 +0000

Логи демона разрастаются, а ротации нет — файл достигает десятков гигабайт, диск забивается, мониторинг ругается. systemd-journald и syslog-ng умеют вращать сами, но если у тебя свой демон пишет напрямую в файл, ротацию несёт logrotate. Вот как его настроить под конкретный сервис.

Зачем писать свой конфиг logrotate

Пакеты из репозитория обычно ставят конфиг в /etc/logrotate.d/, но для自建 демонов или собранных из исходников его нет. Без конфига файл растёт бесконтрольно. logrotate запускается через systemd-таймер (logrotate.timer) или cron и читает все файлы из /etc/logrotate.d/. Достаточно создать один файл — и цикл ротации заработает.

journalctl: фильтрация и форматирование логов systemd

Sun, 06 Sep 2026 00:00:00 +0000

Логи пропали. Сервер перезагрузили — и привычный less /var/log/syslog молчит. В современных дистрибутивах с systemd логи собирает journald, а читает их journalctl. Если не знать его фильтры, работа с системой превращается в гадание.

Почему логи исчезают после перезагрузки

По умолчанию journal хранит данные в /run/log/journal/ — это tmpfs, сбрасывается при ребуте. Чтобы логи переживали перезагрузку, создайте директорию:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

После этого перезапустите systemd-journald:

systemd-run: запуск сервиса без unit-файла

Sat, 05 Sep 2026 00:00:00 +0000

Иногда нужно быстро поднять процесс под systemd, но писать unit-файл и класть его в /etc/systemd/system лень или нельзя — контейнер без systemd, чужая машина, временный запуск. На этот случай есть systemd-run.

Зачем systemd-run

Инструмент создает transient unit — юнит, который существует только в памяти systemd, без файла на диске. Это удобно, когда:

нужен контроль ресурсов (cgroup) над разовым процессом;
важно, чтобы процесс пережил закрытие терминала;
хочется изолировать команду в отдельном слайсе.

По сути, это обертка над systemctl start для юнитов, которые никто не сохраняет.

Создание собственной службы Systemd

Wed, 02 Sep 2026 00:00:00 +0000

Приложение нужно запускать при старте сервера, перезапускать при падении и вести логи. Shell-скрипты в /etc/rc.local не дают ни перезапуска, ни зависимостей. Systemd решает всё это одной декларацией.

Зачем писать свой unit-файл

Вместо скриптов и супервизоров вроде supervisord systemd даёт единый интерфейс управления службами. Он знает о сокетах, зависимостях, ресурсных лимитах и имеет встроенный journald для логов.

Структура unit-файла

Unit-файл — ini-подобный файл в /etc/systemd/system/ или /run/systemd/system/ для runtime. Имя формата имя.service.

systemd-timer: планирование вместо cron

Tue, 01 Sep 2026 00:00:00 +0000

cron работает, но его логи — текстовый файл без структуры, а зависимости от сервисов приходится городить через костыли вроде Requires= в shell-скрипте. systemd-timer решает это: единый интерфейс управления, логи в journald, зависимости через familiar After=, WantedBy= — и всё в одном стеке.

Структура .service и .timer

Таймер — это отдельный юнит, который запускает .service. Разделение故意的: сервис можно вызывать и вручную, и по расписанию.

/etc/systemd/system/
├── backup.service
└── backup.timer

backup.service — обычный юнит, можно запустить через systemctl start backup.service.