Запуск программ при старте Raspberry Pi через systemd

Raspberry Pi на рабочем столе, одноплатный компьютер крупным планом

К чему подойдёт этот материал

Цель: показать, как использовать systemd для запуска программ и скриптов при старте системы на Raspberry Pi. Это полезно, если нужно:

автоматически стартовать демон или серверное приложение;
запускать интерфейсные программы после старта X-сессии;
обеспечить автоматический рестарт при сбоях;
управлять зависимостями между службами.

Варианты применения: мини‑серверы, IoT-проекты, информационные табло, медиасерверы, домашняя автоматизация.

Что такое systemd — кратко

systemd — набор компонентов для управления службами и инициализации в современных Linux-дистрибутивах. systemd запускается первым (PID 1) и следит за стартом, остановкой и перезапуском служб. Unit‑файлы (.service, .socket, .target и др.) описывают, как и когда запускать ресурсы.

Определение в одну строку: unit-файл — это конфигурационный блок, похожий на .ini, который подсказывает systemd, как управлять отдельной единицей (сервисом, сокетом, таргетом).

Важно: существуют и другие способы автозапуска (rc.local, cron @reboot, автозапуск в десктопе), но systemd даёт более тонкий контроль над зависимостями, рестартами и логированием.

Быстрый пример: что мы создадим

Мы создадим systemd unit, который запускает Python-скрипт /home/pi/PiCounter/display.py как сервис display.service. Пример покажет варианты для CLI/демона и для GUI‑приложения.

Пример unit-файла для не‑GUI (демон)

[Unit]
Description=PiCounter
After=network.target

[Service]
ExecStart=/usr/bin/python3 /home/pi/PiCounter/display.py
Restart=always
User=pi

[Install]
WantedBy=multi-user.target

Пояснения кратко:

After=network.target — запускает службу после инициализации сети (но не гарантирует, что сеть онлайн). Для ожидания интернет‑соединения используйте network-online.target и соответствующие Depends/Wants.
ExecStart — полный путь до интерпретатора и скрипта.
Restart=always — рестарт при падении службы.
User — от имени какого пользователя запускать процесс.
WantedBy=multi-user.target — подключает сервис к стандартной целевой конфигурации многопользовательского режима.

Пример unit-файла для GUI‑программы (X11)

[Unit]
Description=PiCounter GUI
After=graphical.target network.target

[Service]
Environment=DISPLAY=:0
Environment=XAUTHORITY=/home/pi/.Xauthority
ExecStart=/usr/bin/python3 /home/pi/PiCounter/display.py
Restart=always
User=pi

[Install]
WantedBy=graphical.target

Пояснения:

Environment=DISPLAY=:0 — указывает дисплей X.
Environment=XAUTHORITY=/home/pi/.Xauthority — файл авторизации X (важно для доступа к X-серверу).
WantedBy=graphical.target — запускается в графическом режиме (после запуска X‑сервера).

Примечание: в средах Wayland или нестандартных сессиях отображения переменные отличаются.

Пошаговая инструкция

Создайте unit-файл в каталоге /etc/systemd/system/ или /lib/systemd/system/ (рекомендуется /etc для локальных правок):
- sudo nano /etc/systemd/system/display.service
Вставьте содержимое unit-файла (пример выше).
Сохраните (Ctrl+O, Enter), закройте редактор (Ctrl+X).
Обновите конфигурацию systemd (не всегда обязательно): sudo systemctl daemon-reload
Запустите сервис вручную для теста: sudo systemctl start display.service
Проверьте статус и логи:
- sudo systemctl status display.service
- sudo journalctl -u display.service –no-pager -n 200
Если всё хорошо — включите автозапуск: sudo systemctl enable display.service
Перезагрузите систему: sudo reboot

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

Отладка: что делать, если сервис не стартует

Проверить синтаксис unit-файла и права доступа:
- sudo systemctl daemon-reload
- sudo systemctl status display.service
Посмотреть логи через journalctl:
- sudo journalctl -u display.service -b
Убедиться, что ExecStart указывает корректный абсолютный путь до исполняемого файла и что файл исполняем (для скриптов: chmod +x /home/pi/PiCounter/display.py при необходимости).
Проверить переменные окружения и файл .Xauthority при GUI.
Убедиться, что сервис запускается от нужного пользователя: если приложение требует доступ к /dev или другим ресурсам, добавьте группу или права.
Проверить SELinux/AppArmor (если используется) — у Raspberry Pi обычно не включены по умолчанию.

Частые ошибки и решения:

“Permission denied” при запуске: проверьте права и владельца файлов; используйте User= и Group= в unit-файле или sudo для теста.
Service падает сразу: проверьте формат unit-файла и путь ExecStart; запустите команду вручную под тем же пользователем.
GUI не видит дисплей: проверьте DISPLAY и XAUTHORITY, или используйте графический таргет.

Зависимости и порядок старта

systemd управляет порядком старта через директивы:

After= — указывает порядок (после чего запускать). Не устанавливает жёсткой зависимости.
Wants= и Requires= — задают зависимости. Requires= делает жёсткую зависимость: если зависимая единица не запустилась, то и эта не будет считаться успешно запущенной.
WantedBy= — определяет, к какому таргету прикрепить unit при enable.

Пример: если вашему сервису нужно, чтобы сеть была полностью online, используйте:

[Unit] After=network-online.target Wants=network-online.target

Это укажет systemd ждать процедур, которые обеспечивают реальное поднятие сети.

Безопасность и права

Не запускайте сложные приложения от root без необходимости. Укажите User=pi или создайте отдельного пользователя и ограничьте права.
Используйте PrivateTmp=true, ProtectSystem=full и другие опции безопасности для ограничения окружения процесса, если приложение не требует доступа к системе.
Для доступа к аппаратному оборудованию (GPIO, I2C, SPI) добавьте пользователя в соответствующие группы (gpio, i2c) и проверьте udev правила.

Пример безопасных опций в unit-файле:

[Service]
User=pi
Group=pi
PrivateTmp=true
ProtectSystem=full
NoNewPrivileges=true

Эти параметры снижают риски при исполнении сервисов.

Альтернативы systemd (когда их выбрать)

rc.local — простой скрипт, выполняемый при старте; хорош для очень простых задач, но мало гибкости.
cron @reboot — удобен для запуска задач при старте, но не даёт управления зависимостями и рестартами.
автозапуск в средах рабочего стола (autostart .desktop) — подходит только для GUI‑сессий.

Выбирайте systemd, если нужна надёжность, рестарт, логирование и контроль зависимостей. Для одношаговых простых действий подойдёт rc.local или cron.

Шаблоны и варианты: что ещё можно добавить в unit

Полезные директивы и примеры:

ExecStartPre= — команда(ы) перед основным запуском для подготовки среды.
ExecStartPost= — команды после успешного старта.
RestartSec= — задержка перед рестартом.
TimeoutStartSec= и TimeoutStopSec= — таймауты на старте/остановке.
EnvironmentFile=/etc/default/myapp — для вынесения конфигурации в файл.
WorkingDirectory=/home/pi/PiCounter — установить рабочий каталог.

Пример с ExecStartPre и EnvironmentFile:

[Service]
EnvironmentFile=/etc/default/picounter
ExecStartPre=/bin/sleep 2
WorkingDirectory=/home/pi/PiCounter
ExecStart=/usr/bin/python3 /home/pi/PiCounter/display.py
Restart=on-failure

Чек‑лист перед деплоем (роль‑зависимый)

Для разработчика:

Проверить, что скрипт корректно работает вручную под нужным пользователем.
Логи выводятся в stdout/stderr (systemd их перехватит).
Добавлен Restart= при необходимости.

Для системного администратора:

Unit размещён в /etc/systemd/system/ и имеет правильные права.
Проверена совместимость с другими service/target.
Настроены опции безопасности (PrivateTmp, NoNewPrivileges).

Для хоббиста/энтузиаста:

Указан DISPLAY/XAUTHORITY для GUI.
Проверены права на доступ к GPIO/камерам.
Сделан резервный план (ssh-доступ) в случае проблем.

Playbook: быстрый SOP для развёртывания сервиса

Подготовьте и протестируйте скрипт вручную.
Создайте unit в /etc/systemd/system/ с корректным ExecStart и User.
sudo systemctl daemon-reload
sudo systemctl start <имя>.service
sudo systemctl status <имя>.service && sudo journalctl -u <имя>.service -n 200
Исправьте ошибки, если есть логика запуска.
sudo systemctl enable <имя>.service
Перезагрузите устройство и проверьте: sudo systemctl status <имя>.service

Критерии приёмки

Сервис считается успешно развёрнутым, если выполнены все пункты:

Сервис стартует автоматически после перезагрузки без вмешательства.
Приложение выполняет свою основную функцию (функциональный тест). Например, на информационном табло отображаются данные.
Логи не содержат критических ошибок в течение N минут работы (ручное наблюдение или мониторинг).
Приложение корректно рестартует при аварийном завершении (если задан Restart=).

Тесты и критерии проверки

Примеры тестов:

Функциональный тест: при запуске службы приложение возвращает HTTP 200 /status.
Стабильность: форсируйте падение процесса и проверьте, что systemd его восстановит.
Права: убедитесь, что служба не имеет лишних прав и не использует root, если это не требуется.

Критерии приёмки формализовать можно в виде простых shell‑скриптов, проверяющих статус systemctl и ответ вашего сервиса.

Решение распространённых задач и лучшие практики

Логи: используйте systemd‑логирование и при необходимости перенаправляйте логи в файлы или в системный агрегатор (rsyslog, fluentd).
Конфигурация: храните настраиваемые параметры в /etc/default или в EnvironmentFile и не правьте unit-файлы для изменения поведения.
Рестарт: для циклических задач рассмотрите Restart=on-failure вместо always, чтобы избежать бесконечного цикла рестартов при некорректной конфигурации.

Совместимость и миграция

На Raspberry Pi OS (на базе Debian) systemd используется по умолчанию, поэтому описанные методы применимы прямо «из коробки».
Для альтернативных оконных систем (Wayland) или кастомных дисплейных менеджеров потребуется адаптация переменных DISPLAY/XAUTHORITY или использование системных хуков DM (display manager).
При миграции с rc.local/cron перенесите логику в unit и добавьте ExecStartPre при необходимости для подготовки среды.

Короткий словарь (1‑строчная справка)

unit — единица конфигурации systemd (.service, .socket, .target и т. д.).
ExecStart — команда, которую запускает systemd для данного unit.
WantedBy — показывает, к какому таргету будет привязан unit при enable.
journalctl — утилита для просмотра логов systemd.

Методология быстрого принятия решения (какой метод выбрать)

Нужна простота и это одноразовый запуск: rc.local или cron @reboot.
Нужен контроль зависимостей, рестарт и логирование: systemd.
Это GUI‑приложение, запускаемое только после входа в сессию: autostart/.desktop или systemd с graphical.target и XAUTHORITY.

Диаграмма принятия решения

flowchart TD
  A[Хочу запустить программу при старте] --> B{Нужен GUI?}
  B -- Да --> C{Запускать после входа в сессию?}
  C -- Да --> D[autostart '.desktop' в сессии пользователя]
  C -- Нет --> E[systemd с graphical.target + XAUTHORITY]
  B -- Нет --> F{Нужен рестарт/зависимости?}
  F -- Да --> G[systemd .service]
  F -- Нет --> H[cron @reboot или rc.local]

Тонкие моменты и подводные камни

Разница между network.target и network-online.target: первый указывает порядок инициализации, второй — фактическую готовность сети. Для приложений, которые требуют доступ в интернет, используйте network-online.target и соответствующие сетевые сервисы.
DISPLAY и XAUTHORITY: если у вас несколько X‑сессий, DISPLAY может отличаться от :0; убедитесь, что подставляете корректное значение.
Права доступа к аппаратуре: для доступа к GPIO/CAMERA используйте группы и udev‑правила; не поднимайте сервис от root без нужды.

Заключение

systemd — универсальный инструмент для автозапуска программ на Raspberry Pi. Он даёт чёткий контроль над порядком запуска, перезапусками и логированием. Для большинства продвинутых проектов systemd — лучший выбор; для простых однократных задач подойдёт cron или rc.local.

Важно: тестируйте ваши unit‑файлы вручную перед включением автозапуска, прописывайте корректные права и не давайте лишних привилегий сервисам.

Summary:

Создайте unit-файл и поместите в /etc/systemd/system/.
Используйте ExecStart, User, Restart и WantedBy для контроля.
Тестируйте через systemctl start/stop/status и journalctl.
Применяйте дополнительные директивы безопасности и зависимости по необходимости.