User-служба исчезает после выхода: когда нужен loginctl enable-linger

Фоновый агент запущен через systemctl --user и исправно работает, пока открыт SSH-сеанс. После выхода пользователя через некоторое время процесс исчезает. Перезапуск по SSH возвращает всё на место. Сначала это похоже на сигнал от терминала, но служба уже отделена от обычного shell-процесса. Теперь нужно проверить жизненный цикл пользовательского менеджера systemd.

User-unit принадлежит менеджеру конкретного пользователя. Это другой контекст, чем системная служба с параметром User=. У него собственные units, окружение и цели запуска. Если агент должен работать без интерактивного входа, наличие менеджера после logout становится частью требований. Настройка lingering позволяет сохранять этот менеджер и запускать его при загрузке.

Проверить нужного пользователя

Посмотрите свой user-unit, а затем состояние lingering. Ниже команды для пользователя deploy; проверку пользовательской службы выполняют в его сеансе.

systemctl --user status worker.service
loginctl show-user deploy -p Linger

Если агент действительно должен жить без входа, администратор может выполнить loginctl enable-linger deploy. Для запуска самого агента при старте пользовательского менеджера его также нужно включить через systemctl --user enable worker.service, а в Install обычно используют WantedBy=default.target. Lingering сохраняет менеджер, но не превращает любой существующий файл unit в автоматически запускаемую службу.

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

Повторить проверку без открытого сеанса

После настройки проверьте unit из текущего входа, затем завершите все сеансы этого пользователя и подождите дольше обычной задержки остановки менеджера. С другого административного аккаунта посмотрите процесс и состояние user manager. После нового входа изучите journalctl --user -u worker.service: важно установить, продолжался ли тот же процесс или агент был заново запущен при логине.

Второй полезный сценарий — перезагрузка учебной машины без последующего входа deploy. Если агент нужен сразу после загрузки, проверка только logout не покрывает это требование. При этом сетевые ресурсы и смонтированные пользовательские каталоги могут иметь свой момент готовности: долгоживущий менеджер не создаёт их автоматически.

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

Продолжить практику

За одной настройкой unit обычно стоит весь путь сопровождения приложения: отдельный пользователь, права на данные, сеть, журналы и повторяемые операции. В программе курса «Linux и Bash для DevOps-инженеров» эти задачи собраны вокруг учебного сервера с приложением под systemd. В практике предусмотрены Bash-скрипты проверки состояния и резервного копирования, а также runbook для воспроизводимых поломок. Это подходящее продолжение, если хочется связать отдельные команды в понятный порядок диагностики.

Посмотреть программу курса

Источник: официальная документация.

Другие задачи по теме: Запуск и жизненный цикл служб systemd.