Исправление сбоя службы systemd 203 / EXEC (нет такого файла или каталога)

Я пытаюсь настроить простой таймер systemd для запуска сценария bash каждый день в полночь.

systemctl --user status backup.service выходит из строя и регистрирует следующее:

backup.service: Failed at step EXEC spawning /home/user/.scripts/backup.sh: No such file or directory.

backup.service: Main process exited, code=exited, status=203/EXEC
Failed to start backup.
backup.service: Unit entered failed state.
backup.service: Failed with result 'exit-code'.

Я потерялся, так как файлы и каталоги существуют. Скрипт исполняемый, и, чтобы проверить, я даже установил права доступа 777.

Немного предыстории:

Файлы модулей backup.timer и backup.service находятся в /home/user/.config/systemd/user.

backup.timer загружен, активен и в настоящее время ожидает полуночи.

Вот как это выглядит:

[Unit]
Description=Runs backup at 0000

[Timer]
OnCalendar=daily
Unit=backup.service

[Install]
WantedBy=multi-user.target

Вот backup.service:

[Unit]
Description=backup

[Service]
Type=oneshot
ExecStart=/home/user/.scripts/backup.sh

[Install]
WantedBy=multi-user.target

И, наконец, это пересказ backup.sh:

#!/usr/env/bin bash

rsync -a --delete --quiet /home/user/directory/ /mnt/drive/directory-backup/

Скрипт работает нормально, если я сам его выполню.

Не уверен, что это важно, но я использую fish в качестве оболочки (начиная с .bashrc).

Я буду рад опубликовать полный сценарий, если он будет вам полезен.


person dwrz    schedule 19.08.2017    source источник
comment
Что выводит ls -l /home/user/.scripts/backup.sh? Начало вашего сценария backup.sh выглядит очень странно: #!/user/env/bin bash, действительно ли существует исполняемый файл /user/env/bin? Вы уверены, что не имели в виду /usr/bin/env или /home/user/bin/env?   -  person nos    schedule 20.08.2017
comment
ls выходы -rwxrwxrwx 1 dwrz dwrz 1470 Aug 11 01:57 /home/user/.scripts/backup.sh. И мои извинения - опечатка в shebang была, когда я копировал вещи сюда. Это /usr/ в сценарии.   -  person dwrz    schedule 20.08.2017
comment
В сторону: начинать рыбу с .bashrc - действительно плохая идея. Обновите запись /etc/passwd, чтобы напрямую указать fish, не путайте программы, которые могут намеренно запускать интерактивный экземпляр bash, заставляя его запускать другую несовместимую оболочку.   -  person Charles Duffy    schedule 20.08.2017
comment
Что касается непосредственной проблемы, я бы начал с воспроизведения ее с Sysdig, отслеживающего выполнение; таким образом вы можете найти точный системный вызов, который не работает, и извлечь соответствующие детали (активный PATH, uid, gid и т. д.).   -  person Charles Duffy    schedule 20.08.2017
comment
Кстати, установлен ли PATH при вызове вашей службы? Если env bash не может найти bash из-за отсутствия PATH, это вызовет вашу ошибку. Установка Environment=PATH=/bin:/usr/bin или другого заведомо исправного значения в .service не повредит.   -  person Charles Duffy    schedule 20.08.2017
comment
Большое спасибо, Чарльз. Я не устанавливал fish в /etc/passwd, как не рекомендует Arch Wiki, но Я ценю поднятую голову и тоже займусь этим. На данный момент я попробовал две вещи: (1) указать PATH в служебном файле, (2) просто использовать #!/bin/bash в сценарии (который все еще работает нормально, когда я сам выполняю его). Я все еще получаю ту же ошибку с systemd (обязательно daemon-reload). Я сейчас посмотрю на sysdig.   -  person dwrz    schedule 20.08.2017
comment
Заглянув в / var / messages, можно получить более подробную информацию об ошибке. Также у serverfault есть вопросы по этой теме, см. serverfault.com/questions/957084   -  person Attila Csipak    schedule 29.07.2020


Ответы (6)


Думаю, я нашел ответ:

В файле .service мне нужно было добавить /bin/bash перед путем к скрипту.

Например, для службы backup.service:

ExecStart=/bin/bash /home/user/.scripts/backup.sh

В отличие от:

ExecStart=/home/user/.scripts/backup.sh

Не знаю почему. Возможно fish. С другой стороны, у меня есть другой сценарий, работающий для моей электронной почты, и служебный файл, кажется, работает нормально без /bin/bash. Однако он использует default.target вместо multi-user.target.

В большинстве встреченных мною руководств не добавляется /bin/bash, но затем я увидел этот ТАК ответ, в котором он был, и решил, что стоит попробовать.

Служебный файл выполняет сценарий, а таймер указан в systemctl --user list-timers, так что, надеюсь, это сработает.

Обновление: я могу подтвердить, что сейчас все работает.

person dwrz    schedule 20.08.2017
comment
Это решило проблему для меня. Причина, по которой он работает с другими скриптами, заключается в том, что у них в начале есть шебанг (#! / Bin / bash), а в этом конкретном нет. - person Felix Müller; 05.04.2018
comment
эта работа очень утомительна, написание строки #! сообщает ядру, какой интерпретатор использовать, теперь я должен отразить эту информацию в модульном файле для приложений, которые не являются одиночными -_- what - person ThorSummoner; 19.04.2018
comment
Даже если исполняемый файл не является сценарием bash, например, в моем случае jupyter в CentOS 7, /bin/bash -c "..." необходимо. Я думаю, это потому, что это скрипт на Python, и в самом начале у него есть набор Python. - person WesternGun; 31.05.2018
comment
У скриптов должен быть интерпретатор, иначе они не скрипт. Вам следует исправить сценарий, а не добавлять bash в ваш .service файл. - person mikemaccana; 06.12.2018
comment
Иногда вам нужен chmod +x /home/user/.scripts/backup.sh. - person ST-DDT; 21.02.2019
comment
В моем случае мне не хватало расширения .sh - person nilesh; 06.05.2019
comment
У меня был #!/bin/bash, но он все еще не работал. Не знаю почему, но префикс /bin/bash в файле .service по-прежнему нужен - person Slimer; 24.07.2019
comment
У меня была аналогичная проблема (фоновый процесс файла nodejs в моем случае), и я настроил его так ... Работает как шарм! Однако пришлось изменить права файла, чтобы разрешить его выполнение. - person MrG; 11.12.2019
comment
Это единственное, что у меня сработало - по какой-то причине строка shebang просто не работает с systemd (Ubuntu 18.04), несмотря на все комментарии, говорящие о ее добавлении. Все остальное тоже было настроено правильно - пользователь, группа, рабочий каталог и т. Д. - person stormbeta; 22.03.2021

Для упрощения не забудьте добавить хэш-код в верхнюю часть вашего скрипта ExecStart, т.е.

#!/bin/bash

python -u alwayson.py    
person crizCraig    schedule 09.02.2019

Когда это случилось со мной, это произошло из-за того, что в моем сценарии были окончания строки DOS, что всегда мешало строке shebang в верхней части сценария. Я изменил его на окончание строки Unix, и это сработало.

person ke4ukz    schedule 08.02.2018
comment
Вы спасли мою жизнь! Я просто добавил #!/usr/bin/env bash в первую строку .sh, после чего работал. - person kujiy; 23.04.2018

Сегодня я тоже наткнулся на Main process exited, code=exited, status=203/EXEC, и моя ошибка заключалась в том, что я забыл добавить исполняемый бит в файл.

person Karl Pokus    schedule 19.05.2019
comment
Я пришел сюда и прочитал отмеченный ответ и обнаружил, прежде чем читать ваш ответ, что простое выполнение chmod 700 ‹script› решило мою проблему. Это должно быть отмечено как правильный ответ. Мне не нужно было добавлять / bin / bash ‹script-start›, как указано в отмеченном ответе. - person nikolaosinlight; 05.11.2020

Если это копия / вставка из вашего скрипта, вы переставили эту строку:

#!/usr/env/bin bash

Нет #!/usr/env/bin, вы имели в виду #!/usr/bin/env.

person Ivan Savcic    schedule 18.03.2019
comment
Хорошо поймал! Скрипт сейчас правильный, но, возможно, потом я его исправлю. Если бы это был копипаст, это бы объяснило это. - person dwrz; 19.03.2019

На самом деле я использовал ответ из Как сделать Я запускаю приложение node.js в качестве фоновой службы? в сочетании с тем, что dwrz сказал выше. В моем случае я создавал бота Discord, который должен был работать, когда меня нет рядом.

С этой службой я сначала получил ту же ошибку, что и первоначальный плакат, который привел меня сюда. Мне не хватало #!/usr/bin/env node в верхней части моего выполненного скрипта node.js.

С тех пор никаких проблем, хотя я намерен посмотреть, что еще можно распространить на сам сервис.

person Wirehead    schedule 22.11.2018