User= в systemd: от кого работает служба
Задаёт системного пользователя, от имени которого выполняются процессы службы. Без него служба работает от root, что для большинства служб излишне.
Что делает
Смена пользователя происходит до запуска программы, поэтому все последующие действия — переход в рабочий каталог, открытие файлов вывода, доступ к файлам — выполняются уже от него. Это объясняет, почему проверять права надо через sudo -u, а не от root: root видит совсем другую картину.
Пользователя systemd не создаёт (кроме случая DynamicUser=yes). Он должен существовать в системе на момент запуска, иначе служба падает с кодом 217/USER. Для служб принято завести системного пользователя без оболочки и домашнего каталога.
Где ставится. В секции [Service]. Для служб пользователя (systemctl --user) параметр недоступен.
Значения
| Значение | Что происходит |
|---|---|
app | имя существующего пользователя. |
998 | числовой идентификатор — работает, но читается хуже имени. |
%i | подстановка экземпляра в шаблонном unit. |
Пример
Служба от отдельного пользователя с доступом только к своим каталогам.
[Service]
User=app
Group=app
StateDirectory=myapp
ExecStart=/usr/local/bin/myappПараметр StateDirectory= тут не случайно: systemd сам создаст /var/lib/myapp и назначит владельцем пользователя службы.
Типичные ошибки
Пользователя нет в системе — запуск завершается кодом 217/USER до выполнения программы.
Порты ниже 1024 недоступны обычному пользователю: нужна возможность CAP_NET_BIND_SERVICE или сокет-активация.
После добавления параметра к работавшей службе каталоги и файлы остаются принадлежать root: их нужно передать новому пользователю.
Окружение пользователя (.bashrc, .profile) служба не читает: переменные задаются в unit-файле.
Связанные ошибки
- status=217/USER в systemdКод 217/USER означает, что systemd не смог определить или сменить пользователя из User=. Разбор причин: пользователя нет, имя недопустимо, конфликт с DynamicUser.
- Permission denied в журнале службыОтказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
- bind: Permission denied при привязке к портуОтказ при привязке к порту: обычно порт ниже 1024 у службы от непривилегированного пользователя. Как дать возможность CAP_NET_BIND_SERVICE.
- status=200/CHDIR в systemdКод 200/CHDIR означает, что systemd не смог перейти в каталог из WorkingDirectory= до запуска программы. Причины и решение.
Рядом стоящие параметры
Где важен на практике
Источники
- systemd.exec(5)
- Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)