The scheduled tasks in the Linux system, the crontab is not executed as scheduled, which is a common fault in the operation and maintenance work.
The following in conjunction with the recently deployed automated script does not perform the troubleshooting steps:
1. Check whether the crontab service is normal
[dmdba@test_db ~]$ ps -aux|grep cron
Here it is found that the service is running normally. If no execution record is found in it, you can start this service: service crond start
2. View user emails
In fact, the most direct and effective way is to check the execution log. Combined with the crontab execution record and the system mail after crontab execution error, you can generally find the cause of the failure completely!
Of course, keep in mind that if you block error messages in crontab, no emails will be sent.
[dmdba@test_db ~]$ cat /var/spool/mail/dmdba
Here, I found that the script execution reported an error: the
reason is still an environment variable problem, just find the script export and add the missing environment variable.
3. Check the execution permission of the script
Generally speaking, it is recommended to use sh or bash to execute shell scripts in crontab, so as to avoid task failure due to the loss of execution permissions of script files.
Of course, the most direct check is to manually copy the command line test results in crontab -l.
[dmdba@test_db script]$ crontab -l
0 2 * * * sh /home/dmdba/dmbackup/script/backup.sh
4. Check the variables that the script needs to use
As above, the script executed from crontab is usually different from the environment variable executed manually, so for some system variables, it is recommended to write absolute path, or use witch to dynamically obtain,
For example, sudo_bin=$(which sudo) can get the absolute path of sudo in the current system.