Scenario: You need to start a scheduled task in the cron of the system, run a shell script that basically means to switch to
The ABC user executes a PHP file (for example:/data/soft/auto.php), then the problem now comes, within the script
The following is the capacity:
1234 |
#!/bin/bash sudo -U ABC 
/data/soft/auto
.php
echo ‘ >>> auto success !!! ’
|
You will magically discover that auto success has been shown in the system's/var/log/cron log, but this program still
is not executed, how do you know not to execute it? Because the program has a log, the log does not begin to brush.
So what is the next step to find out why the program is not executing? The idea is that every time cron is executed, it will produce a recorded file.
Find the location of the file based on the system version:
Operating system version 4/5 view/var/spool/clientqueue/
Operating system version 6 view/var/spool/postfix/maildrop/
System postfix stop, do not stop to directly hit the mail command to see
After entering the corresponding directory, you can use the Ls-lt|head command to intercept the last 10 cron log files, judging by the time
Which file, there must be an error. Modify the script or System properties based on an error.
There are two situations I have encountered:
1. Sudo system default warning requires TTY, workaround: comment out Defaults requiretty in the/etc/sudoers file .
2. The variable path is caused by loading the variables or definitions you need.
Long time no write, this problem is worth recording, I believe many people still do not know the wrong way, this is just learned from others.
Moe's IT People
Linux Cron Scheduled Task log tracking