root我已经向的 crontab添加了一个作业
# crontab -l | tail -n 1
*/3,13,29,43 * * * * /root/bin/check_network.sh
#
但是，它似乎正在以我的普通用户身份运行rwb。
该rwb帐户（不是该root帐户）正在收到有关作业失败的邮件，并且失败是因为
/root/bin/check_network.sh: line 26: iw: command not found
但当然iw是/use/sbin/iw在root，$PATH但不是rwb。
这是怎么回事？！如何运行我的根 cron 作业？
更新
将命令从 更改iw为似乎可以使其正常工作，因此cron 运行时与普通 bash 窗口相比/usr/sbin/iw肯定存在一些差异。$PATH
答案1
您su在设置 crontab 时是否使用过 root 身份？
在 Debian 10 上，man crontab说道：
请注意，su(8) 可能会混淆 crontab，并且如果您在 su(8) 内部运行，为了安全起见，您应该始终使用 -u 选项。
su在 Debian 10 版本中，Debian 放弃了代码库中的旧命令shadow-utils，并迁移到了代码库su中util-linux。这导致了许多微妙的变化。
Debian 10 的默认设置允许多人拥有 root 访问权限，并且如果他们愿意的话，在使用 root 权限时仍然可以让他们自己的个人偏好生效。但结果是，仅使用suorsudo -s将导致环境变量的不完全更改：例如，使用 plain从 转换rwb为后，环境变量的值仍然为。rootsuUSERrwb某些程序和脚本使用此变量来识别用户。
因此，如果你去/var/spool/cron/crontabs查看那里的文件，我敢打赌你会发现你的 cron 作业定义实际上是在 中/var/spool/cron/crontabs/rwb，而不是在/var/spool/cron/crontabs/root.实际上，您仍然编辑了自己的个人 crontab 文件，而不是 root 的。
如果您想“完全成为 root”，并完全重新初始化环境变量，则需要使用su -或sudo -i。
答案2
您似乎有问题环境;特别是cron.我搞乱了 2-3 个不同的发行版（主要是 Debian），并且环境并不总是一样的。我使用了一个小技巧来cron告诉我它的环境是什么：
将以下行（或类似行）添加到您的crontab：
@reboot /usr/bin/printenv > /home/my/cronenv.txt 2>&1
将其与交互式 shell 报告的环境进行比较（bash在本例中）：
pi@4b:~ $ printenv
正如您可能会看到的，这两个环境之间存在巨大差异。有改变环境的各种解决方案cron，但就我的目的而言，我发现只需养成调用可执行文件/命令的完整路径的习惯，就无需对环境进行大多数更改cron。
WRT root's crontab，它与您的用户的不同crontab：
pi@4b:~ $ sudo crontab -e
这会让您获得与您的.root crontab完全不同的.user crontab和以前一样，您可以运行printenv来root crontab检查环境中的差异。当你需要的时候提升特权在cron工作中，这是要走的路。
请注意，在某些系统上，这可能会以不同的方式处理，但据我所知，在我的基于 Debian 的系统上，它运行良好。由于您正在以 的身份运行作业/脚本，因此您无需sudo在 中输入权限提升。root crontabcronroot