我已经使用这两个参考来插入一个新的 crontab 条目。
我创建了一个新的 bash 文件并将其移动到 /usr/bin。该 sh 文件对 root 用户和 admin 组具有执行权限。bash 文件只是将一行回显到日志文件，然后调用一个 java 程序。我已以 root 身份手动测试了 sh 文件。它运行良好。我的 crontab 条目如下所示...
@hourly /usr/bin/foo.blah.sh
它应该每小时运行一次。echo 语句没有打印到日志文件中，所以我认为 crond 根本没有调用它。此外，当我在“top”中直观地监控进程时，该作业从未出现。我运行了“service crond status”来验证 cron 守护程序是否正在运行。文档说不需要重新启动守护程序。我还可能做错了什么？
答案1
您实际上并没有说明 crontab 条目在哪里，但根据您crontab -l输出的评论no crontab for root，我大胆猜测您在 /etc/cron.* 目录之一下添加了一个文件，其中包含与各种 cron 作业相对应的文件。此答案假设情况确实如此。
这些文件的格式与您通过 编辑的用户特定 crontab 略有不同crontab -e。具体来说，它们包含一个用户名字段就在命令之前，它不包含在用户特定的 crontab 中（至少在我的系统上它存储在 /var/spool/cron/crontabs 下，但请不要滥用该信息；确切位置是您正在运行的 cron 守护进程的实现细节，您应该使用记录的界面来管理这些文件）。
因此，你应该改变
@hourly /usr/bin/foo.blah.sh
到
@hourly user /usr/bin/foo.blah.sh
user运行脚本的用户帐户名称是哪里。脚本应该可以正常运行。
我真的鼓励你不要运行 cron 任务，root除非你必须这样做；以超级用户身份做任何事情总是存在安全风险。如果可能的话，给脚本一个有限制访问权限的自己的帐户。（这是最小权限原则；也就是说，最少的权限是它完成工作所必需的。）一般来说，你应该将脚本放在系统本地文件放入 /usr/local以避免与系统包管理器发生冲突；另外，为了避免混淆，不要将需要 root 权限才能工作的东西放在任何 bin 目录中，而应该使用 sbin。
答案2
过去，当向 cron 添加脚本时，我总是用 sh 引导行，如下所示：
@hourly sh /usr/bin/foo.blah.sh