Как использовать systemd для запуска сервиса Linux при загрузке

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

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

Что такое systemd и почему это важно?

systemd — это система инициализации и менеджер сервисов, который заменил более старые альтернативы, такие как SysVinit и Upstart, в большинстве основных дистрибутивов Linux, включая Ubuntu, Debian, CentOS, Rocky Linux, AlmaLinux и Fedora. Вместо выполнения последовательной цепочки shell-скриптов при загрузке, systemd параллелизирует запуск сервисов, разрешает порядок зависимостей и управляет полным жизненным циклом системных процессов из единого унифицированного интерфейса.

Ключевые преимущества systemd для серверных сред

Для всех, кто управляет приложениями на Dedicated Servers или экземплярах VPS, эти возможности напрямую переводятся в более высокую доступность и более предсказуемое поведение под нагрузкой.

Понимание файлов модулей systemd

Все, чем управляет systemd, представлено файлом модуля — простым текстовым файлом конфигурации, разделенным на разделы. Файл модуля сервиса сообщает systemd:

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

Файлы модулей сервиса для системных сервисов находятся в /etc/systemd/system/. Файлы, размещенные здесь, имеют приоритет над поставляемыми поставщиком модулями в /lib/systemd/system/ и сохраняются при обновлении пакетов.

Пошагово: создание модуля сервиса systemd

Следующее пошаговое руководство использует вымышленное приложение под названием myapp. Замените каждый экземпляр myapp, myuser и /usr/bin/myapp значениями, подходящими для вашей собственной среды.

Шаг 1: подготовка рабочего каталога

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

Создайте каталог, если он еще не существует:

sudo mkdir -p /opt/myapp

> Почему /opt/ вместо /etc/systemd/?

> Дерево /etc/systemd/ зарезервировано для собственной конфигурации systemd. Размещение данных приложения там нестандартно и может вызвать путаницу. Используйте /opt/myapp, /srv/myapp или /var/lib/myapp в зависимости от категории стандарта иерархии файловой системы, которая лучше всего подходит для вашей рабочей нагрузки.

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

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myuser
sudo chown -R myuser:myuser /opt/myapp

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

Проверьте результат:

ls -ld /opt/myapp
# Expected output: drwxr-xr-x 2 myuser myuser 4096 Jan 1 00:00 /opt/myapp

Шаг 2: создание файла модуля сервиса

Откройте новый файл модуля с помощью предпочитаемого редактора:

sudo nano /etc/systemd/system/myapp.service

Вставьте следующее содержимое, отрегулировав значения в соответствии с вашим приложением:

[Unit]
Description=My Custom Application
Documentation=https://example.com/docs
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/myapp --config /opt/myapp/myapp.conf
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
User=myuser
Group=myuser
WorkingDirectory=/opt/myapp
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapp

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Сохраните файл с помощью Ctrl+O, затем выйдите с помощью Ctrl+X.

Шаг 3: понимание каждой директивы

#### Раздел [Unit]

> network-online.target vs network.target: Используйте network-online.target (в сочетании с Wants=network-online.target) для сервисов, которым действительно нужен полностью настроенный сетевой интерфейс — например, приложение, которое подключается к удаленной базе данных или внешнему API при запуске. network.target гарантирует только, что подсистема сети была *запущена*, а не что интерфейсы включены и адреса назначены.

#### Раздел [Service]

#### Раздел [Install]

Шаг 4: проверка разрешений файла и каталога

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

# Check working directory ownership and permissions
ls -ld /opt/myapp

# Confirm the executable exists and is executable
ls -l /usr/bin/myapp

# Verify the config file is readable by myuser
sudo -u myuser cat /opt/myapp/myapp.conf

Если какая-либо из этих проверок не пройдена, исправьте разрешения перед продолжением:

# Make the binary executable
sudo chmod +x /usr/bin/myapp

# Grant read access to the config file
sudo chmod 640 /opt/myapp/myapp.conf
sudo chown myuser:myuser /opt/myapp/myapp.conf

Шаг 5: ручное тестирование исполняемого файла

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

sudo -u myuser /usr/bin/myapp --config /opt/myapp/myapp.conf

Если приложение запускается без ошибок, нажмите Ctrl+C для его остановки и продолжайте. Если оно не работает, устраните неполадки самого приложения — проверьте, что все зависимости установлены, переменные окружения установлены и требуемые порты доступны.

Шаг 6: перезагрузка systemd и включение сервиса

После сохранения файла модуля дайте systemd указание перечитать его конфигурацию:

sudo systemctl daemon-reload

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

sudo systemctl enable myapp.service

Эта команда создает символическую ссылку в соответствующем каталоге .wants, связывая ваш файл модуля в последовательность загрузки multi-user.target. Вы должны увидеть вывод, похожий на:

Created symlink /etc/systemd/system/multi-user.target.wants/myapp.service → /etc/systemd/system/myapp.service.

Запустите сервис немедленно без перезагрузки:

sudo systemctl start myapp.service

Шаг 7: проверка работы сервиса

Проверьте текущий статус сервиса:

sudo systemctl status myapp.service

Здоровый сервис выдает вывод, подобный этому:

● myapp.service - My Custom Application
     Loaded: loaded (/etc/systemd/system/myapp.service; enabled; vendor preset: disabled)
     Active: active (running) since Wed 2025-01-01 12:00:00 UTC; 5s ago
   Main PID: 12345 (myapp)
      Tasks: 4 (limit: 4915)
     Memory: 12.3M
        CPU: 45ms
     CGroup: /system.slice/myapp.service
             └─12345 /usr/bin/myapp --config /opt/myapp/myapp.conf

Ключевые поля для проверки:

• Loaded — подтверждает, что файл модуля был успешно проанализирован и показывает, включен ли он enabled или disabled для загрузки
• Active: active (running) — сервис в настоящее время работает
• Main PID — идентификатор процесса вашего приложения

Шаг 8: мониторинг журналов с помощью journalctl

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

# View all logs for myapp (most recent last)
journalctl -u myapp.service

# Follow live log output (like tail -f)
journalctl -u myapp.service -f

# Show only logs since the last boot
journalctl -u myapp.service -b

# Show the last 50 lines
journalctl -u myapp.service -n 50

# Show logs since a specific time
journalctl -u myapp.service --since "2025-01-01 12:00:00"

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

Шаг 9: тестирование поведения при загрузке

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

# Reboot the server (only if safe to do so)
sudo reboot

После того как сервер вернется в сеть, проверьте статус сервиса еще раз:

sudo systemctl status myapp.service

Если он показывает active (running), ваш сервис правильно настроен для автоматического запуска.

Управление жизненным циклом сервиса

После того как ваш сервис запущен, вы будете регулярно использовать следующие команды:

Общие команды systemctl

# Start the service
sudo systemctl start myapp.service

# Stop the service gracefully
sudo systemctl stop myapp.service

# Restart the service (stop + start)
sudo systemctl restart myapp.service

# Reload configuration without restarting (if ExecReload is defined)
sudo systemctl reload myapp.service

# Enable automatic startup at boot
sudo systemctl enable myapp.service

# Disable automatic startup at boot
sudo systemctl disable myapp.service

# Check whether the service is enabled
sudo systemctl is-enabled myapp.service

# Check whether the service is currently active
sudo systemctl is-active myapp.service

# View the full unit file as systemd interprets it
sudo systemctl cat myapp.service

# Edit the unit file and reload in one step
sudo systemctl edit --full myapp.service

Устранение распространенных проблем

Сервис не запускается: “No such file or directory”

Это обычно означает, что ExecStart указывает на несуществующий двоичный файл или WorkingDirectory не существует. Проверьте оба пути:

which myapp
ls -l /opt/myapp

Сервис запускается, но сразу же выходит

Проверьте журнал на предмет собственного вывода об ошибках приложения:

journalctl -u myapp.service -n 100 --no-pager

Также проверьте, что Type=simple правильный для вашего приложения. Если ваш двоичный файл разветвляется в фоне, используйте вместо этого Type=forking.

Ошибки “Permission denied”

Пользователь сервиса не имеет доступа к требуемому файлу или каталогу. Используйте ls -l для аудита разрешений и sudo -u myuser для интерактивной проверки доступа.

Порт уже используется

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

sudo ss -tlnp | grep :<port>

Сервис перезапускается в цикле

Если Restart=on-failure вызывает циклы быстрого перезапуска, systemd в конечном итоге будет регулировать перезапуски. Проверьте StartLimitIntervalSec и StartLimitBurst в разделе [Unit] для настройки этого поведения и всегда исследуйте основную причину в журнале.

Продвинутые шаблоны systemd для производственных серверов

Переменные окружения и файлы окружения

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

###PPT_NOTR