Systemd: Почему он стал стандартом и как им эффективно управлять

Если ваш дистрибутив Linux был выпущен после 2010 года, то, вероятно, за запуск всех системных служб, монтирование файловых систем и даже выполнение запланированных задач отвечает systemd. Это не просто инициализационный демон, а полноценный системный менеджер, пришедший на смену разрозненным скриптам /etc/init.d/, планировщику cron и части инструментов мониторинга.

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

Основные компоненты: Юниты systemd (Units)

Все объекты, которыми управляет systemd, называются юнитами. Каждый юнит имеет свой тип и соответствующий конфигурационный файл, который определяет его поведение и параметры.

Наиболее важные типы юнитов:

• .service: Служба или демон (например, Nginx, SSH).
• .mount: Точка монтирования файловой системы.
• .timer: Задание, выполняемое по расписанию (современная замена cron).
• .target: Группа других юнитов, используемая для достижения определенного состояния системы (аналог уровней загрузки в традиционных системах init).

Базовые команды для управления системой

Systemd предоставляет набор мощных команд, которые заменяют множество устаревших инструментов.

1. Управление службами (с помощью systemctl)

Эти команды приходят на смену service и прямым вызовам скриптов из /etc/init.d/.

sudo systemctl start nginx    # Запустить службу
sudo systemctl stop nginx     # Остановить службу
sudo systemctl restart nginx  # Перезапустить службу
sudo systemctl enable nginx   # Включить автозапуск службы при загрузке системы
sudo systemctl disable nginx  # Отключить автозапуск службы

2. Просмотр состояния и логов (с помощью systemctl и journalctl)

Заменяет комбинации ps aux | grep и tail -f.

sudo systemctl status nginx   # Показать текущее состояние службы, последние записи в журнале и запущенные процессы
sudo journalctl -u nginx -f   # Отслеживать логи службы в реальном времени
sudo journalctl -u nginx --since today  # Просмотреть логи службы за текущий день

3. Просмотр зависимостей и списка юнитов

sudo systemctl list-dependencies nginx  # Отобразить список зависимостей для запуска службы nginx
sudo systemctl list-units --type=service --state=running  # Показать все запущенные службы

Практический пример: Анализ вывода systemctl status

Выполните команду sudo systemctl status ssh, и вы увидите детализированный вывод, подобный следующему:

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2024-01-30 09:00:00 UTC; 1h ago
       Docs: man:sshd(8)
   Main PID: 1234 (sshd)
      Tasks: 1 (limit: 1137)
     Memory: 5.2M
     CGroup: /system.slice/ssh.service
             └─1234 /usr/sbin/sshd -D [listener] 0 of 10-100 startups

Вся необходимая информация представлена в одном месте: статус загрузки конфигурации (Loaded), текущее состояние службы (Active), время запуска, PID главного процесса (Main PID), потребление системных ресурсов (Memory), а также ссылки на документацию (Docs).

Когда что использовать?

• systemctl: Ваш основной инструмент для управления службами, контроля автозапуска и просмотра общего состояния юнитов.
• journalctl: Применяется для просмотра и анализа системных логов, эффективно заменяя tail и grep для файлов в /var/log/.
• systemd-analyze: Используется для анализа времени загрузки системы и выявления узких мест.

Важно отметить, что многие старые команды, такие как service или прямые вызовы скриптов /etc/init.d/script, в современных дистрибутивах чаще всего являются просто обертками, которые под капотом вызывают соответствующие команды systemctl.

Благодаря systemd, вместо изучения десятков разрозненных команд для управления системой, достаточно освоить единую логику systemctl. Это значительно упрощает администрирование, особенно в критических ситуациях, когда требуется быстро перезапустить службу и оперативно выяснить причину сбоя.