I am going to create a crontab task to schedule my task.
My /etc/crontab looks like this,
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
17 15 * * * root sh /opt/app/tool/ReviewSummaryTool/runf.sh
The task script runf.sh has content looks like this,
#!/usr/bin/env bash
java -Dhostname=$(hostname) -jar ReviewSummaryTool.jar -full
But the crontab task could not be executed (I checked the output log) when time is arrived.
However, the task script could be execute by command below,
sh /opt/app/tool/ReviewSummaryTool/runf.sh
And I checked the log of crontab at /var/log/cron and it seems that the task has already been executed. See brief log content below,
Aug 31 15:17:01 SSECBIGDATA01 crond[1677]: (*system*) RELOAD (/etc/crontab)
Aug 31 15:17:01 SSECBIGDATA01 CROND[29248]: (root) CMD (sh /opt/app/tool/ReviewSummaryTool/runf.sh)
Now, I have no idea what's wrong with my configuration. My operating system is CentOS.
Any help would be appreciate. Thanks in advance.
For debugging purposes replace sh with /bin/sh -vx in the crontab entry:
17 15 * * * root /bin/sh -vx /opt/app/tool/ReviewSummaryTool/runf.sh
Then the trace of the executed script will be printed, so emailed to you.
And add logger commands inside your runf.sh script, e.g. have it be
#!/bin/sh
logger -t runfjob start of runf pid $$ in $(pwd) on host $(hostname)
java -Dhostname=$(hostname) -jar ReviewSummaryTool.jar -full
logger -t runfjob end of runf pid $$
The logger command makes entries to the system log using syslog(3). You should find these messages under /var/log, perhaps in /var/log/messages or /var/log/syslog etc...
I strongly suggest to put the full path of the ReviewSummaryTool.jar file in the java command of your runf.sh script. It is likely that your cronjob is run in a current directory not having that file. Or perhaps put a cd command before the java one.
Be sure that the $PATH is correct and that java is found there.
Related
i have some issue on running shell script to execute jar file in opensuse,
Below is the way set for crontab:
contrab -e
5 */1 * * * /path to shellscript/run.sh
Below is the way shell script contain:
#! bin/sh
cd /project/jar/
/usr/local/jdk1.8/bin/java -jar /project/jar/pike.jar
From the file above already given chmod 777 permission.
Is there anything wrong about the setting? if i execute the shell script it run directly, from tracing systemlog follow by /var/log/message, from here able to check crontab is execute with the job id display. From the java log file it doesn't show anything.
Please help on this. thank you.
All we know that cron ignores variables defined in “.bashrc” and “.bash_profile”, so we have to define it inside cron. I constantly do the same what was written inside the similar question https://unix.stackexchange.com/questions/67940/cron-ignores-variables-defined-in-bashrc-and-bash-profile but still global variables inside .bashrc still not working. I found way to execute it - by defining sh script with "set +a" bashrc script. But "source" still doesn't work.
SHELL=/bin/bash
BASH_ENV=/root/.bashrc
PATH=:/opt/spark/spark-2.2.0-bin-hadoop2.7/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SPARK_HOME=/opt/spark/spark-2.2.0-bin-hadoop2.7
MAILTO=root HOME=/
# m h dom mon dow command
* * * * * /bin/bash -c 'source $HOME/.bashrc; echo "SPARK_HOME: '$SPARK_HOME'"; echo "JAVA_HOME: '$JAVA_HOME'"' > /var/log/file.log 2>&1
# DO NOT DELETE LAST LINE
return log file
SPARK_HOME: /opt/spark/spark-2.2.0-bin-hadoop2.7
JAVA_HOME:
also tried to execute this in interactive mode as it was written by mklement0
source .bashrc in a script not working
* * * * * /bin/bash -i source /root/.bashrc; echo $JAVA_HOME > /var/log/file.log 2>&1
As you can see SPARK_HOME is defined inside crontab whilst JAVA_HOME only in .bashrc. P.S in bashrc java home is defined "export JAVA_HOME=/usr/jdk1.8.0_131"
All different cron jobs work fine when I change JAVA_HOME to SPARK_HOME, tried different crontab jobs but the answer is the same as it was.
ubuntu kernel version is
uname -a
Linux 6101c32b9243 4.9.62-21.56.amzn1.x86_64 #1 SMP Thu Nov 16 05:37:08 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Your last attempt runs bash and sources the file, then exits Bash and runs the echo in the calling shell, which isn't Bash, and of course doesn't know or care that the now-defunct Bash process loaded some settings and then forgot them when it exited. (Or, well, this is what would happen if you fixed the simple quoting errors to keep the source command and its argument as a single string.)
The superficial fix is easy;
* * * * * bash -c 'source $HOME/.bashrc; echo "$JAVA_HOME"' >/var/log/file.log 2>&1
The proper fix, however, is probably to encapsulate all of this in a separate script and keep your crontab really simple.
(Are you really sure your user is allowed to overwrite the log file? Replacing the log once a minute seems rather misdirected, although it's good enough for a quick test to see if the job is running at all.)
I would like to run a specific script at a certain time (only once!). If I run it normally like this:
marc#Marc-Linux:~/tennis_betting_strategy1/wrappers$ Rscript write_csv2.R
It does work. I however would like to program it in a cronjob to run at 10:50 and therefore did the following:
50 10 11 05 * Rscript ~/csv_file/write_csv.R
This does not seem to work however. Any thoughts where I go wrong? These are the details of the cron package im
using:
PID COMMAND
1015 cron
My system time also checks out:
marc#Marc-Linux:~/tennis_betting_strategy1/wrappers$ date
wo mei 11 10:56:46 CEST 2016
There is a special tool for running commands only once - at.
With at you can schedule a command like this:
at 09:05 am today
at> enter you commands...
Note, you'll need the atd daemon running.
Your crontab entry looks okay, however. I'd suggest checking if the cron daemon is running(exact daemon name depends on the cron package; it could be cron, crond, or vixie-cron, for instance). One way to check if the daemon is running is to use the ps command, e.g.:
$ ps -C cron -o pid,args
PID COMMAND
306 /usr/sbin/cron
Some advices.
Read more about the PATH variable. Notice that it is set differently in interactive shells (see your ~/.bashrc) and in cron or at jobs. See also this about Rscript.
Replace your command by a shell script, e.g. in ~/bin/myrscriptjob.sh
That myrscriptjob.sh file should start with #!/bin/sh
Be sure to make that shell script executable:
chmod u+x ~/bin/myrscriptjob.sh
Add some logging in your shell script, near the start; either use logger(1) or at least some date(1) command suitably redirected, or even both:
#!/bin/sh
# file myrscriptjob.sh
/bin/date +"myrscriptjob starting %c %n" > /tmp/myrscriptjob.start
/usr/bin/logger -t myrscript job starting $$
/usr/local/bin/Rscript $HOME/csv_file/write_csv.R
in the last line above, replace /usr/local/bin/Rscript by the output of which Rscript done in some interactive terminal.
Notice that you should not use ~ (but replace them with $HOME when appropriate) in shell scripts.
Finally, use at to run your script once. If you want to run it periodically in a crontab job, give the absolute path, e.g.
5 09 11 05 * $HOME/bin/myrscriptjob.sh
and check in /tmp/myrscriptjob.start and in your system log if it has started successfully.
BTW, in your myrscriptjob.sh script, you might replace the first line #!/bin/sh with #!/bin/sh -vx (then the shell is verbose about execution, and cron or at will send you some email). See dash(1), bash(1), execve(2)
Use full path (started from /) for both Rscript and write_csv2.R. Check sample command as follows
/tmp/myscript/Rscript /tmp/myfile/write_csv2.R
Ensure you have execution permission of Rscript and write permission in folder where write_csv2.R will be created(/tmp/myfile)
I created a cronjob with the command crontab -e:
*/1 * * * * /var/lib/tomcat/webapps/ROOT/WEB-INF/scripts/test.sh
This file test.sh should be executed every minute. But it doesn't work.
If I run the script manually it works fine. So I think the problem is the cronjob not the script ;)
Are there any permissions or something else which block the cronjob?
Is the cronjob syntax correct?
Thx
For a start, you don't need the /1 if you want it done every minute. Just setting the minute field to * will do.
Next, you should place, as the first lines in your test script (though after the #! line if it's there):
env >/tmp/test.sh.dummy
set >>/tmp/test.sh.dummy
and see if that file shows up.
That will tell you if the script is running or not.
If it's not running, check to make sure cron itself is running:
pax> ps -ef | grep cron | grep -v grep
root 1048 1 0 08:45 ? 00:00:00 cron
(mine is).
If it is running, the most likely problem is that the environment under which cron runs your jobs is nowhere near the environment your shell gives you. Examine the differences between what was output to your /tmp/test.sh.dummy file and what your shell gives your when you execute env ; set.
I'm using a basic shell script to log the results of top, netstat, ps and free every minute.
This is the script:
/scripts/logtop:
TERM=vt100
export TERM
time=$(date)
min=${time:14:2}
top -b -n 1 > /var/log/systemCheckLogs/$min
netstat -an >> /var/log/systemCheckLogs/$min
ps aux >> /var/log/systemCheckLogs/$min
free >> /var/log/systemCheckLogs/$min
echo "Message Content: $min" | mail -s "Ran System Check script" email#domain.com
exit 0
When I run this script directly it works fine. It creates the files and puts them in /var/log/systemCheckLogs/ and then sends me an email.
I can't, however, get it to work when trying to get cron to do it every minute.
I tried putting it in /var/spool/cron/root like so:
* * * * * /scripts/logtop > /dev/null 2>&1
and it never executes
I also tried putting it in /var/spool/cron/myservername and also like so:
* * * * * /scripts/logtop > /dev/null 2>&1
it'll run every minute, but nothing gets created in systemCheckLogs.
Is there a reason it works when I run it but not when cron runs it?
Also, here's what the permissions look like:
-rwxrwxrwx 1 root root 326 Jul 21 01:53 logtop
drwxr-xr-x 2 root root 4096 Jul 21 01:51 systemCheckLogs
Normally crontabs are kept in "/var/spool/cron/crontabs/". Also, normally, you update it with the crontab command as this HUPs crond after you're done and it'll make sure the file gets in the correct place.
Are you using the crontab command to create the cron entry? crontab to import a file directly. crontab -e to edit the current crontab with $EDITOR.
All jobs run by cron need the interpreter listed at the top, so cron knows how to run them.
I can't tell if you just omitted that line or if it is not in your script.
For example,
#!/bin/bash
echo "Test cron jon"
When running from /var/spool/cron/root, it may be failing because cron is not configured to run for root. On linux, root cron jobs are typically run from /etc/crontab rather than from /var/spool/cron.
When running from /var/spool/cron/myservername, you probably have a permissions problem. Don't redirect the error to /dev/null -- capture them and examine.
Something else to be aware of, cron doesn't initialize the full run environment, which can sometimes mean you can run it just fine from a fully logged-in shell, but it doesn't behave the same from cron.
In the case of above, you don't have a "#!/bin/shell" up top in your script. If root is configured to use something like a regular bourne shell or cshell, the syntax you use to populate your variables will not work. This would explain why it would run, but not populate your files. So if you need it to be ksh, "#!/bin/ksh". It's generally best not to trust the environment to keep these things sane. If you need your profile run the do a ". ~/.profile" up front as well. Or a quick and dirty way to get your relatively full env is to do it from su as such "* * * * * su - root -c "/path/to/script" > /dev/null 2>&1
Just some things I've picked up over the years. You're definitely expecting a ksh based on your syntax, so you might want to be sure it's using it.
Thanks for the tips... used a little bit of each answer to get to the bottom of this.
I did have the interpreter at the top (wasn't shown here), but may have been wrong.
Am using #!/bin/bash now and that works.
Also had to tinker with the permissions of the directory the log files are being dumped in to get things working.