5 главных команд systemctl для повышения продуктивности в Linux

Системы Linux полагаются на фоновые службы практически для всего: SSH-доступ, сеть, ведение журналов, веб-серверы, базы данных, запланированные задачи и экраны входа в систему рабочего стола. Когда одна из этих служб начинает работать неправильно, systemctl обычно становится первым инструментом, к которому вы обращаетесь.

systemctl — это основной интерфейс командной строки для systemd, менеджера служб, используемого во многих основных дистрибутивах Linux. Вам не нужно запоминать каждую подкоманду, чтобы быть эффективным. В повседневной работе небольшой набор команд покрывает большинство проверок служб, перезапусков, изменений конфигурации загрузки и обновлений файлов модулей.

Понимание Systemd и systemctl

Прежде чем углубиться в команды, давайте кратко рассмотрим systemd и systemctl. systemd отвечает за инициализацию системы, управление службами, обработку процессов и многое другое. Он заменяет старые системы инициализации, такие как SysVinit и Upstart, предлагая более быстрое время загрузки, параллельный запуск служб и более надежное управление зависимостями. systemctl — это ваше окно в мир systemd, позволяющее контролировать и запрашивать состояние служб, модулей и целей.

«Модуль» (unit) в терминологии systemd относится к любому ресурсу, которым systemd умеет управлять. Службы (.service), точки монтирования (.mount), устройства (.device), сокеты (.socket) и цели (.target) являются распространенными типами модулей. В рамках этой статьи мы в первую очередь сосредоточимся на модулях служб, которые представляют процессы-демоны, управляемые systemd.

5 главных команд systemctl для повышения продуктивности

Вот пять команд systemctl, которые значительно улучшат вашу способность управлять службами вашей системы Linux и отслеживать их.

1. systemctl status [ИМЯ_СЛУЖБЫ]

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

Почему это продуктивно: Быстрая диагностика проблем, подтверждение запуска/остановки службы и получение снимка состояния службы без ручного просмотра файлов журналов.

Пример: Чтобы проверить состояние веб-сервера Apache (httpd.service в некоторых дистрибутивах, apache2.service в других, таких как Debian/Ubuntu):

systemctl status apache2.service

Интерпретация вывода (пример):

● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-10-26 10:00:00 UTC; 1min 2s ago
       Docs: https://httpd.apache.org/docs/2.4/
    Process: 1234 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
   Main PID: 1239 (apache2)
      Tasks: 6 (limit: 4639)
     Memory: 21.6M
        CPU: 184ms
     CGroup: /system.slice/apache2.service
             ├─1239 /usr/sbin/apache2 -k start
             ├─1240 /usr/sbin/apache2 -k start
             └─1241 /usr/sbin/apache2 -k start

Oct 26 10:00:00 servername systemd[1]: Starting The Apache HTTP Server...
Oct 26 10:00:00 servername systemd[1]: Started The Apache HTTP Server.

Этот вывод сообщает вам:

• Loaded: Где находится файл модуля и включен ли он для запуска при загрузке.
• Active: Текущий статус (например, active (running), inactive (dead), failed).
• Недавние записи журнала из journalctl.

Совет: Нажмите q, чтобы выйти из режима просмотра состояния.

Две детали в status легко упустить. Во-первых, Loaded: сообщает вам, существует ли файл модуля и включен ли он для загрузки. Служба может быть active (running) и все еще быть disabled; это означает, что она была запущена вручную или другой зависимостью, но не обязательно запустится при следующей загрузке. Во-вторых, последние строки журнала — это только предварительный просмотр. Если полезная ошибка ушла за пределы экрана, используйте journalctl -u apache2.service вместо попыток выжать все из status.

Для скриптов и проверок мониторинга предпочтительнее использовать машиночитаемые команды:

systemctl is-active --quiet apache2.service
systemctl is-enabled apache2.service

is-active --quiet завершается с кодом состояния 0, когда служба активна. Это делает ее полезной в небольшой проверке работоспособности:

if ! systemctl is-active --quiet apache2.service; then
  echo "apache2 не запущен"
fi

2. systemctl start|stop|restart [ИМЯ_СЛУЖБЫ]

Назначение: Эти команды дают вам прямой контроль над жизненным циклом службы во время выполнения.

• start: Запускает службу.
• stop: Останавливает работающую службу.
• restart: Останавливает, а затем запускает службу (полезно для применения изменений конфигурации).

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

Примеры: Чтобы остановить веб-сервер Apache:

sudo systemctl stop apache2.service

Чтобы снова его запустить:

sudo systemctl start apache2.service

Чтобы перезапустить его после изменения файлов конфигурации:

sudo systemctl restart apache2.service

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

Используйте restart осторожно на производственных службах. Он останавливает процесс и запускает его снова, что может разорвать активные соединения, если приложение не обрабатывает корректное завершение работы должным образом. Если модуль поддерживает перезагрузку, это часто лучше после изменения только конфигурации:

sudo systemctl reload nginx.service

Не каждая служба поддерживает перезагрузку. Проверьте определение модуля, прежде чем предполагать это:

systemctl cat nginx.service | grep ExecReload

Если ExecReload= отсутствует, systemctl reload обычно завершится ошибкой. В этом случае вы либо перезапускаете службу, либо используете команду перезагрузки, специфичную для приложения.

3. systemctl enable|disable [ИМЯ_СЛУЖБЫ]

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

• enable: Настраивает службу на автоматический запуск при загрузке. Это создает символическую ссылку из соответствующего каталога цели systemd на файл модуля службы.
• disable: Предотвращает автоматический запуск службы при загрузке путем удаления символической ссылки.

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

Примеры: Чтобы гарантировать, что Apache запускается каждый раз при загрузке системы:

sudo systemctl enable apache2.service

Чтобы предотвратить запуск ненужной службы (например, cups.service, если вы не используете печать) при загрузке:

sudo systemctl disable cups.service

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

Помните, что enable и disable влияют только на поведение при загрузке. Они не запускают и не останавливают службу прямо сейчас. Если вы хотите выполнить оба действия вместе, используйте:

sudo systemctl enable --now apache2.service
sudo systemctl disable --now cups.service

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

4. systemctl list-unit-files --type=service

Назначение: Эта команда выводит список всех файлов модулей служб systemd, известных вашей системе, вместе с их статусом enabled или disabled. Это невероятно полезно для получения общего обзора того, какие службы настроены в вашей системе.

Почему это продуктивно: Помогает обнаружить установленные службы, выявить ненужные и провести аудит конфигурации загрузки вашей системы. Это мощный инструмент для разведки и очистки системы.

Пример:

systemctl list-unit-files --type=service

Частичный вывод (пример):

UNIT FILE                                  STATE
acpid.service                              enabled
aptd-auto-update.service                   static
apt-daily.service                          static
apache2.service                            enabled
avahi-daemon.service                       enabled
bluetooth.service                          enabled
cups.service                               enabled
... (много других служб)

78 unit files listed.

Совет: Столбец STATE указывает, настроена ли служба на запуск при загрузке (enabled), явно предотвращен (disabled) или static (не может быть включена/отключена напрямую с помощью systemctl enable/disable, часто это зависимости или внутренние модули systemd).

Фильтрация: Вы можете передать вывод в grep, чтобы найти конкретные службы:

systemctl list-unit-files --type=service | grep ssh

Когда вас интересуют работающие службы, а не установленные файлы модулей, используйте list-units:

systemctl list-units --type=service --state=running
systemctl list-units --type=service --state=failed

Это различие важно при очистке. list-unit-files сообщает вам, что systemd знает, как запустить. list-units сообщает вам, что systemd загрузил в свое текущее состояние выполнения.

5. systemctl daemon-reload

Назначение: После изменения файла модуля systemd (например, создания нового файла службы в /etc/systemd/system/ или редактирования существующего) systemd не распознает эти изменения автоматически. systemctl daemon-reload дает команду systemd повторно просканировать все файлы модулей и перезагрузить их конфигурации.

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

Пример: Предположим, вы создали новый файл модуля службы для своего пользовательского приложения mywebapp.service.

1. Создайте /etc/systemd/system/mywebapp.service.

2. Перезагрузите конфигурацию systemd:

sudo systemctl daemon-reload ```

1. Теперь systemd знает о mywebapp.service, и вы можете выполнять start, enable, status:

sudo systemctl start mywebapp.service sudo systemctl enable mywebapp.service systemctl status mywebapp.service ```

Важно: daemon-reload перезагружает только определения модулей. Если служба уже запущена, изменения в ее файле модуля не вступят в силу до перезапуска службы (systemctl restart [ИМЯ_СЛУЖБЫ]).

Простой ежедневный рабочий процесс

Когда я попадаю на незнакомый сервер, я обычно работаю в таком порядке:

systemctl status sshd.service
systemctl list-units --type=service --state=failed
systemctl list-unit-files --type=service | grep enabled
systemctl get-default

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

Для изменения службы рабочий процесс так же короток:

sudo systemctl edit myapp.service
sudo systemctl daemon-reload
sudo systemctl restart myapp.service
systemctl status myapp.service
journalctl -u myapp.service -n 50 --no-pager

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

Несколько полезных вариаций

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

Чтобы увидеть только модули со сбоями:

systemctl --failed

Это одна из самых быстрых проверок после перезагрузки. Если обновление пакета изменило модуль, точка монтирования вышла по тайм-ауту или пользовательская служба вылетела во время загрузки, это часто отобразится здесь до того, как пользователь сообщит о проблеме.

Чтобы проверить точное содержимое модуля, загруженное systemd:

systemctl cat docker.service

Это важно, потому что файл, который вы помните редактировали, может быть не полной историей. Пакетный модуль в /usr/lib/systemd/system/ может быть изменен одним или несколькими дополнениями (drop-ins) в /etc/systemd/system/docker.service.d/. systemctl cat показывает объединенное представление, чтобы вы не отлаживали не тот файл.

Чтобы увидеть, почему служба запускается при загрузке:

systemctl list-dependencies multi-user.target
systemctl list-dependencies graphical.target

Это помогает, когда кто-то спрашивает: «Почему это работает?». Служба может быть включена напрямую, притянута целью, активирована сокетом или запущена другим модулем. Поведение при загрузке часто является вопросом зависимостей, а не просто вопросом «включено или отключено».

Чтобы проверить недавние журналы без открытия пейджера:

journalctl -u sshd.service -n 50 --no-pager

systemctl status дает небольшой предварительный просмотр журнала, но journalctl дает вам контроль над временным диапазоном, загрузкой, количеством строк и форматом вывода. Например:

journalctl -u sshd.service --since "today" --no-pager
journalctl -u sshd.service -b -1 --no-pager

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

Нет награды за использование самой длинной команды systemctl. Продуктивность приходит от знания того, какая маленькая команда отвечает на текущий вопрос: работает ли она, должна ли она запускаться при загрузке, что вышло из строя, что изменилось и перезагрузил ли systemd определение, которое я редактировал?

Еще одна привычка помогает на общих машинах: оставляйте свидетельства того, что вы изменили. Если вы отключаете службу, запишите причину в своей заявке, регламенте или журнале изменений. Через шесть месяцев кто-то может увидеть disabled и предположить, что это ошибка. Команда проста:

sudo systemctl disable --now old-worker.service

Операционный контекст — это та часть, которую люди теряют. Была ли она заменена таймером? Вызывала ли она дублирование задач? Была ли она нужна только во время миграции? systemctl может показать состояние, но не может объяснить намерение. Краткая заметка рядом с изменением удерживает следующего человека от отмены хорошего решения.