Распространенная ситуация: запускаете приложение руками и все работает.
/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