我已經使用這兩個引用來插入一個新的 crontab 條目。
我創建了一個新的 bash 檔案並將其移至 /usr/bin。該sh檔案具有root使用者和admin群組的執行權限。 bash 文件只是將一行回顯到日誌文件，然後呼叫 java 程式。我已經以 root 身分手動測試了 sh 檔案。它運行良好。我的 crontab 條目看起來像這樣...
@hourly /usr/bin/foo.blah.sh
它應該在每個整點運行。 echo 語句沒有列印到日誌檔案中，所以我認為 crond 根本沒有呼叫它。此外，當我直觀地監視「頂部」中的進程時，該作業永遠不會出現。我已執行「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