Работал ли с systemd

Что проверяют

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

Как отвечать

Расскажите про юнит и про то, что в нём важно именно для сервиса на Go.

[Service]
ExecStart=/usr/local/bin/app --config /etc/app/config.yaml
EnvironmentFile=/etc/app/env
User=app
Restart=on-failure
RestartSec=5s
TimeoutStopSec=30s

Дальше назовите рабочие мелочи: после правки юнита нужен systemctl daemon-reload, включение с запуском это systemctl enable --now, логи читаются через journalctl -u app -f. Писать в файл не нужно, отправляйте всё в стандартный вывод, journald подберёт сам.

Обязательно скажите про остановку: по SIGTERM сервис завершается сам, через signal.NotifyContext и Shutdown у сервера, иначе по истечении таймаута прилетит SIGKILL и оборвёт запросы на лету. Полезно упомянуть ограничения и изоляцию (LimitNOFILE, MemoryMax, ProtectSystem, PrivateTmp) и таймеры systemd как замену cron, с OnCalendar и Persistent.

Где спотыкаются

Правят юнит и не делают daemon-reload, потом долго ищут, почему изменения не применились. То же с enable: сервис работает ровно до первой перезагрузки.

Ставят Restart=always сервису, который падает на старте из-за конфигурации. Получается цикл перезапусков, systemd упирается в предел частоты и глушит юнит совсем, а причину ищут в systemd, а не в своём конфиге.

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