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

[asyncmonk]

Написал unit-файл для своего скрипта, вручную через systemctl start он запускается нормально. Но после reboot — не стартует, статус failed. В journalctl вижу: 'Failed to start My Service — Start request repeated too quickly.' Что за бред, почему при ручном старте работает, а при автозапуске нет? Вот мой unit:
[Service]
ExecStart=/opt/myapp/start.sh
Restart=always

[kingpaul]

Классика! Проблема скорее всего в том, что при загрузке сервис пытается стартовать до того, как поднялась сеть или смонтировались нужные диски. Добавь в секцию [Unit] строки After=network.target и After=local-fs.target — и почти наверняка поможет.

[guardia]

Ошибка 'repeated too quickly' означает, что сервис крашится и systemd пытается его перезапустить слишком часто, в итоге сдаётся. Это не проблема порядка загрузки — это проблема самого скрипта. Запусти journalctl -u твой-сервис.service -n 50 --no-pager и смотри что там реально происходит при старте.

[spark_pilot]

Вот полный рабочий пример unit-файла, который решает оба варианта проблемы:

[Unit]
Description=My Application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/opt/myapp/start.sh
Restart=on-failure
RestartSec=5s
StartLimitIntervalSec=60
StartLimitBurst=3

[Install]
WantedBy=multi-user.target

Ключ: Restart=on-failure вместо always (не будет перезапускать при нормальном завершении), RestartSec=5s — пауза между попытками, StartLimitBurst=3 — максимум 3 попытки за 60 секунд. И обязательно network-online.target если скрипт лезет в сеть — это именно 'сеть готова', а не просто 'сетевой интерфейс поднят'.

[spaegree]

Ещё проверь: скрипт start.sh имеет права на выполнение? chmod +x /opt/myapp/start.sh. Звучит банально, но при ручном запуске от рута может работать, а systemd по умолчанию может запускать от другого пользователя.

[smith_zhenya]

После изменения unit-файла не забудь systemctl daemon-reload, иначе systemd работает со старой версией файла. Я раз 20 на это наступил.

[hunter22]

Судя по тому, что ты показал только [Service] — а секция [Install] с WantedBy=multi-user.target в юните вообще есть? Проверь systemctl is-enabled твой-сервис. И почти наверняка дело в окружении: при ручном systemctl start у тебя уже всё загружено, а при буте скрипт стартует в голом окружении с минимальным PATH. Добавь в начало start.sh строки set -x и exec >> /tmp/myapp-boot.log 2>&1, перезагрузись — и в логе будет видно, на какой именно команде он умирает в первые секунды загрузки.

[nerd_max]

@spark_pilot, шаблон хороший, одна правка: StartLimitIntervalSec и StartLimitBurst по документации живут в секции [Unit], а не в [Service]. В [Service] они срабатывают только благодаря легаси-совместимости, и на части версий systemd молча игнорируются — человек скопирует, а лимиты не применятся. Лучше сразу перенести в [Unit], тогда поведение предсказуемое везде.

[coldpanic]

@guardia, плюсую, «repeated too quickly» — это всегда вторичная ошибка, она маскирует первопричину. Дополню: чтобы смотреть именно момент загрузки, удобнее journalctl -b -u сервис — покажет лог с текущего бута без шума от прошлых запусков. И частый виновник там — сеть: After=network.target не гарантирует поднятый линк, target срабатывает раньше, чем появился адрес. Если скрипт сразу куда-то коннектится, нужны network-online.target плюс Wants, иначе крашлуп при буте обеспечен.