修复 systemd 服务 203/EXEC 故障（没有这样的文件或目录）答案

【问题标题】：Fixing a systemd service 203/EXEC failure (no such file or directory)修复 systemd 服务 203/EXEC 故障（没有这样的文件或目录）
【发布时间】：2018-01-28 06:47:03
【问题描述】：

我正在尝试设置一个简单的 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 作为我的 shell（从 .bashrc 开始）。

如果有帮助，我很乐意发布完整的脚本。

【问题讨论】：

ls -l /home/user/.scripts/backup.sh 输出什么？你的 backup.sh 脚本的开头看起来很奇怪：#!/user/env/bin bash，可执行文件 /user/env/bin 真的存在吗？你确定你说的不是/usr/bin/env 或/home/user/bin/env 吗？
ls 输出-rwxrwxrwx 1 dwrz dwrz 1470 Aug 11 01:57 /home/user/.scripts/backup.sh。我很抱歉——shebang 中的错字是我把东西复制到这里的时候。在脚本中是/usr/。
旁白：从.bashrc 开始钓鱼是一个真的坏主意。更新您的 /etc/passwd 条目以直接指定 fish，不要混淆可能有意运行交互式 bash 实例的程序，使其启动不同的、不兼容的 shell。
至于眼前的问题，我先用Sysdig跟踪执行来重现它；这样您就可以找到失败的确切系统调用并提取相关详细信息（活动 PATH、uid、gid 等）。
顺便说一句，是否在调用您的服务时设置了PATH？如果env bash 找不到bash 因为没有PATH，那会导致你的错误。在.service 中设置Environment=PATH=/bin:/usr/bin 或其他已知良好的值不会有任何影响。

标签： bash systemd

【解决方案1】：

尝试运行：

systemctl daemon-reload

然后再次运行

service <yourservice> status

【讨论】：

【解决方案2】：

我今天也遇到了Main process exited, code=exited, status=203/EXEC，我的错误是我忘记将可执行位添加到文件中。

【讨论】：

我来到这里并阅读了标记的答案，并在阅读您的答案之前发现，只需执行 chmod 700

【解决方案3】：

如果这是从您的脚本中复制/粘贴，那么您已经改变了这一行：

#!/usr/env/bin bash

没有#!/usr/env/bin，你的意思是#!/usr/bin/env。

【讨论】：

不错的收获！脚本现在是正确的，但我可能会在之后修复它。如果它是复制粘贴，那就可以解释了。

【解决方案4】：

为简化起见，请确保在 ExecStart 脚本的顶部添加一个井号，即

#!/bin/bash

python -u alwayson.py

【讨论】：

【解决方案5】：

我实际上使用了How do I run a node.js app as a background service? 的答案，并结合了 dwrz 上面所说的内容。就我而言，我正在创建一个 Discord 机器人，它需要能够在我不在的时候运行。

有了这项服务，我最初遇到了与最初的海报相同的错误，这将我带到了这里。我在执行的 node.js 脚本顶部缺少#!/usr/bin/env node。

从那时起，没有任何问题，尽管我打算看看还有什么可以扩展到服务本身。

【讨论】：

【解决方案6】：

当这发生在我身上时，是因为我的脚本有 DOS 行尾，这总是会弄乱脚本顶部的 shebang 行。我将其更改为 Unix 行尾，它工作正常。

【讨论】：

你救了我的命！我刚刚在.sh 的第一行添加了#!/usr/bin/env bash 然后工作了。

【解决方案7】：

我想我找到了答案：

在.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，但后来我看到了this SO answer which had it，并认为值得一试。

服务文件执行脚本，计时器列在systemctl --user list-timers，所以希望这能工作。

更新：我可以确认现在一切正常。

【讨论】：

这为我解决了。它与其他脚本一起使用的原因是它们在开头有一个 shebang (#!/bin/bash)，而这个特定的脚本没有。
这个解决方法非常烦人，写一个#! 行告诉内核使用什么解释器，现在我必须将这些信息镜像到一个单元文件中，用于不是单例的应用程序 -_-什么
即使可执行文件不是 bash 脚本，例如在我的例子中，jupyter 在 CentOS 7 上，/bin/bash -c "..." 也是必要的。我想是因为它是一个python脚本，一开始就有一个python的shebang。
脚本应该有解释器，否则它们就不是脚本。您应该修复脚本，而不是将 bash 添加到您的 .service 文件中。
有时您需要chmod +x /home/user/.scripts/backup.sh。