我在我的用戶上使用 Crontab 來運行很多curl 腳本,它們工作正常,其中 40 個工作正常。
但是我在根 Crontab 中使用命令“sudo crontab -e”的腳本沒有運行,它們在大約 1 個月前停止工作,並且運行良好超過 2 年。
嘗試與伺服器人員交談,但他們都不知道可能出了什麼問題。順便說一句,我不是伺服器專家,我可以遵循指南,但僅此而已:)
我嘗試過:重新啟動cron服務,“安裝新的crontab”,使用root用戶在普通crontab中運行腳本,重新啟動伺服器,刪除檔案中的所有內容,刪除MAILTO。
所有腳本只需手動運行即可工作。
這是不起作用的罰款:
郵件地址=“”
2 3 * * * "/usr/local/scripts/backup-mysql.sh"
25 3 * * * "/usr/local/scripts/backup-prestashop.sh"
答案1
最有幫助的應該是取得錯誤訊息。
2 3 * * * { date; bash -v "/usr/local/scripts/backup-mysql.sh"; date; } &>/tmp/cron-backup-mysql.log
25 3 * * * { date; bash -v "/usr/local/scripts/backup-prestashop.sh"; date; } &>/tmp/cron-backup-prestashop.log
輸出記錄在/tmp/cron-backup-mysql.log
和中/tmp/cron-backup-prestashop.log
。 bash -v
在讀取腳本時輸出腳本行。
您可以檢查文件的擁有者以確保它以 root 身份運行。然後讀取文件,您有開始和結束時間來檢查運行是否完成以及持續時間是否符合您的預期。
如果腳本現在正確運行,則問題可能是隱式呼叫的 shell(bash -v
從 crontab 中刪除並新增echo SHELL = $SHELL
至腳本)或腳本缺少執行權限 ( chmod +x
)。
如果腳本崩潰,bash -v
將幫助您找到錯誤。您可以透過替換-v
為顯示更多詳細信息-x
,但這會在計算每個表達式時淹沒輸出。