Manually execute the sh script in CentOS, call the java program, everything is normal;
After adding the sh to the crontab for regular scheduling, it hangs up, and there is no feeling of execution at all! ! !
View the crontab execution log:
cat /var/log/cron has execution records,
Is it possible to use crontab to call the execution will report an error, print the log first:
crontab -e
40 10 * * * /home/job.sh 2>>/home/log
Schedule it again and view the log:
cat /home/log
Really wrong:
Exception in thread "main" java.lang.ClassFormatError: SystemInfo (unrecognized class file version)
...
Unrecognized java version, boldly suspecting that the environment variables used by crontab are his own:
cat /etc/crontab
Sure enough, crontab itself has a PATH variable, modify it:
vim /etc/crontab
Re-use crontab to call the program, the error remains the same, restart it:
service crond restart
Call again, continue to report errors, is the PATH of crontab a decoration!
Google Zhi, Baidu Zhi, it turns out that this is a problem with countless people, the following are some useful information found:
http://xiachaofeng.iteye.com/blog/1405184
I encountered a problem today. The crontab's scheduled tasks cannot be executed automatically, but the manual execution of the script has always been successful. In the end, it was found that the system environment variables were used in the script. Let's start explaining:
1.crontab and environment variables
Don't assume that cron knows the special environment it needs, it doesn't. So you want to make sure to provide all the necessary paths and environment variables in the shelll script, except for some global variables that are automatically set. So pay attention to the following 3 points:
1) Write the global path when the file path is involved in the script;
2) When java or other environment variables are used for script execution, environment variables are introduced through the source command, such as:
cat start_cbp.sh
#!/bin/sh
source /etc/profile
export RUN_CONF=/home/d139/conf/platform/ cbp/cbp_jboss.conf
/usr/local/jboss-4.0.5/bin/run.sh -c mev &
3) When the script is executed manually, it is OK, but the crontab is not executed. At this time, you must boldly suspect that the environment variable is to blame, and you can try to directly introduce the environment variable in crontab to solve the problem. For example:
0 * * * * . /etc/profile;/bin/sh /var/www/java/audit_no_count/bin/restart_audit.sh
2. Other issues that should be noted
1) The newly created cron job will not be executed immediately, and it will take at least 2 minutes to execute. If you restart cron, it will be executed immediately.
2) After each job is executed, the system will automatically send the output to the current system user by email. Over time, there will be a lot, and it will even burst the entire system. So it is very necessary to perform redirection processing after each JOB command: >/dev/null 2>&1 . The premise is that the normal output of the commands in the Job has been processed to a certain extent, such as appending to a specific log file.
3) When crontab suddenly fails, you can try /etc/init.d/crond restart to solve the problem. Or check the log to see if a job is executed/errored tail -f /var/log/cron.
4) Do not run crontab -r indiscriminately. It removes the user's Crontab file from the Crontab directory (/var/spool/cron). Deleted all crontabs for that user and it's gone.
5) In crontab, % has a special meaning, which means newline. If you want to use it, you must escape \%. For example, the frequently used date '+%Y%m%d' will not be executed in crontab, it should be replaced with date '+\%Y\%m\%d' `.
3. Output configuration in crontab
In crontab, the output of running scripts is often configured as: >/dev/null 2>&1 to avoid content output in crontab operation.
The result of the shell command can be defined by the form of '>'
/dev/null represents an empty device file
> represents where to redirect to, for example: echo "123" > /home/123.txt
1 means stdout standard output, the system default value is 1, so ">/dev/null" is equivalent to "1>/dev/null"
2 means stderr standard error
& means equal to, 2>&1, means that the output redirection of 2 is equivalent to 1
Then the meaning of the redirected output statement:
1>/dev/null first means that the standard output is redirected to an empty device file, that is, no information is output to the terminal, and no information is displayed.
2>&1 means that standard error output redirection is equivalent to standard output, because standard output has been redirected to an empty device file before, so standard error output is also redirected to an empty device file.