NetworkAdmin.ru

😑 Почему сервис работает вручную, но падает в systemd Распространенная ситуация: запускаете приложение руками и все работает.

/opt/myapp/start.sh

А через systemd:

systemctl start myapp

сервис падает, не видит файлы, не находит переменные, не может подключиться к сокету или пишет что-то вроде: No such file or directory Permission denied command not found И тут важно понять главное: запуск руками и запуск через systemd - это не одно и то же окружение. Когда вы запускаете команду из shell, у вас уже есть: переменные окружения; текущий каталог; пользовательская сессия; PATH; ssh-agent; загруженный профиль .bashrc / .profile; права вашего пользователя. А systemd запускает сервис гораздо строже. ▪️Самые частые причины: Нет нужного PATH. В shell команда находится, а в systemd нет. Плохо:

ExecStart=python app.py

Лучше:

ExecStart=/usr/bin/python3 /opt/myapp/app.py

Другой рабочий каталог. Скрипт ожидает файлы рядом с собой, а systemd запускает его не оттуда.

WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/start.sh

Не хватает переменных окружения. Например, DB_HOST, API_TOKEN, JAVA_HOME.

Environment="DB_HOST=127.0.0.1"
EnvironmentFile=/etc/myapp/myapp.env

Не тот пользователь. Вручную запускали от root, а сервис работает от myapp.

User=myapp
Group=myapp

И внезапно выясняется, что нет прав на логи, конфиги или каталоги данных. Сервис стартует раньше зависимости. Например, приложение поднимается раньше базы, сети или mount point.

After=network-online.target postgresql.service
Wants=network-online.target

Скрипт требует интерактивную оболочку. Если внутри завязка на .bashrc, алиасы, read, sudo с паролем или интерактивные команды - в systemd это почти гарантированно сломается. Что смотреть первым делом:

systemctl status myapp
journalctl -u myapp -xe
systemctl cat myapp

Полезно вывести окружение процесса:

systemctl show myapp -p Environment

И проверить unit на синтаксис:

systemd-analyze verify /etc/systemd/system/myapp.service

#linux #systemd 🧑‍💻 NetworkAdmin