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.
Related
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 know this question has been asked many, many times and I've done a lot of research but still I'm not able to run this extremely simple cron:
$ crontab -l
* * * * * /bin/date
This should, ideally, print the date every minute.
There is no cron.allow or cron.deny file, and the cron daemon is working:
ps -e | grep cron
1119 ? 00:00:00 cron
17646 ? 00:00:00 cron
Any idea what might be wrong?
Cron processes run in a separate subprocess of their own, so the output of a cron job will not be visible to you in your shell.
Instead, you will have to capture the output of your cron commands and save them. So, set your cronjob like:
* * * * * /bin/date >> /home/user/date.log
And now, if you will tail this log file, you will start seeing the result.
I have a very simple script in my crontab that I want to run every day. It is located in /home:
-rwxr-xr-x 1 root root 40 Apr 15 08:01 kill_slony_stop_sql.sh
It has execute permission and here is the content:
#!/bin/bash
slon_kill;rcpostgresql stop
and here is the cron line for it to run daily:
56 12 * * * /home/kill_slony_stop_sql.sh
But it is not working for some reason. When I type /home/kill_slony_stop_sql.sh in the command line, it works good but it is not working in the crontab.
Any thoughts?
It is most likely a PATH issue. Have a look at Why is my crontab not running and be sure to set a PATH so that it can call your slon_kill command.
Also, add some debug to your cron
56 12 * * * /home/kill_slony_stop_sql.sh &>/tmp/errorcron.log
And also look at the logs; cron logs its actions via syslog, which (depending on your setup) often go to /var/log/cron or /var/log/syslog.
I had the same problem with a daily cron job, I used the #daily but this will run at 00:00 every day.
#daily /usr/local/bin/msa70_check.sh
was the cron tab line i added, below is the script i run.
#!/bin/bash
# msa70 disk check
/sbin/mdadm --detail /dev/md0 /dev/md1|
/bin/mailx -s"Disk check on server123 please check" person#domain.com
I also had to edit my script and add /sbin/ and /bin in front of mdadm and mailx for the cron job to run
I am trying to make a cron job for the first time but i have some problems making it work.
Here is what i have done so far:
Linux commands:
crontab -e
My cronjob looks like this:
1 * * * * wget -qO /dev/null http://mySite/myController/myView
Now when i look in:
/var/spool/cron/crontabs/
I get the following output:
marc root
if i open the file root
i see my cronjob (the one above)
However it doesnt seem like it is running.
is there a way i can check if its running or make sure that it is running?
By default cron jobs do have a log file. It should be in /var/log/syslog (depends on your system). Vouch for it and you're done. Else you can simply append the output to a log file manually by
1 * * * * wget http://mySite/myController/myView >> ~/my_log_file.txt
and see what's your output. Notice I've changed removed the quiet parameter from wget command so that there is some output.
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.