I want to automatically start a program if it crashes (check if the process exists, if not, restart it), so using crontab is a simple solution, but
I creatd a simple crontab task using crontab -e or in /etc/crontab file like this:
* * * * * /usr/bin/gnome-terminal
it doesn't work, it never launches gnome-terminal, I can see it executes the task in /var/log/syslog (Ubuntu) or /var/log/cron (CentOS), the gnome-terminal never comes up.
if you say since gnome-terminal is a gui program, then, this script to create bluetooth service won't work either :
using crontab -e or /etc/crontab:
* * * * * /home/username/run-bt
run-bt:
#!/bin/sh
# find bt pid
/usr/bin/pgrep bluetoothd
# if not running
if [ $? -ne 0 ]
then
/usr/sbin/service bluetooth restart
fi⏎
I already made the run-bt script executable, but bluetooth service won't start even if I stop the bluetooth service manually.
but this:
* * * * * /bin/ls > /tmp/ls.output
works as expected.
What's wrong?
Actually crontab does not load all the environment variables of the current user it runs for, just a few of them.
Maybe some of those environment variables are required by the scripts you try to run?
Related
I am trying to create a cron job that will change my desktop wallpaper every minute. I created a new job using crontab -e.
*/1 * * * * /usr/bin/nitrogen --set-zoom-fill --random /home/rkr/Pictures/wallpapers-master/
The command works on the shell very well. The cron job is also running and visible in /var/log/syslog.
I tried to debug it by sending the output to a log file, which reports a warning about nitrogen :
(nitrogen:10468): Gtk-WARNING **: 09:37:01.654: cannot open display:
I don't think that is the issue though. To further verify if my cron is working I tried :
*/1 * * * * touch /home/rkr/Videos/file and the file was created.
Now I am confused if this is the issue with nitrogen.
Hello
It depends...
I think the issue is the environment.
Having a Terminal open in X and type:
env | grep DISPLAY
This gives the information you need to set the Display for nitrogen.
Because the cronjob sh/bash dont have this variable set.
Now your best friend is env too for starting nitrogen in crontab.
env -i DISPLAY=:0.0 nitrogen
...much fun.
I have made the following cronjob sh file :
Vi RestartServices.sh
/etc/init.d/b1s stop
sleep 10
/etc/init.d/sapb1servertools stop
sleep 10
sudo -u ndbadm /usr/sap/NDB/HDB00/HDB stop
sleep 20
sudo -u ndbadm /usr/sap/NDB/HDB00/HDB start
sleep 10
/etc/init.d/sapb1servertools start
sleep 10
/etc/init.d/b1s start
When I run this file manually the job runs correctly.
When scheduled in crontab (root user)
Crontab content:
# srvmagtCron: restarts daemons that died
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /bin/sh -c "[ -x /etc/srvmagt/srvmagtCron ] && /etc/srvmagt/srvmagtCron"
0 2 * * * /hanamnt/shared/NDB/HDB00/backup/scripts/VGRbackup.sh
#RESTARTS SERVICE LAYER , SAPB1ServerTools service , HDB
0 3 * * * /hanamnt/shared/NDB/HDB00/backup/scripts/RestartServices.sh
It does get started at the requested time but I think it failed to execute the sudo line as the HDB service has not been restarted.
I'm trying to find out why?
Is it because sudo cannot be executed in a cronjob?
(service needs to start using user ndbadm)
path:
/opt/sap/sapjvm_6//bin:/opt/fujitsu/bwai/bin:/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib64/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
You have a non-standard $PATH and crond(8) is running your crontab(5) entries with a shorter $PATH. See also environ(7), credentials(7) and execvp(3) with execve(2)
My recommendation would be to write a complete shell script, and put only that in crontab. So don't use sh -c in crontab entries, and set explicitly the PATH (either, and preferably, in the shell scripts your crontab entry is firing, or maybe in your crontab file).
You could for example have
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /hanamnt/shared/srvmagt.sh
in your crontab, and have an executable /hanamnt/shared/srvmagt.sh file starting with
#!/bin/bash
export PATH=/opt/sap/sapjvm_6//bin:/opt/fujitsu/bwai/bin:/sbin:\
/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:\
/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:\
/usr/lib64/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
# log a starting message
logger start of $0
Notice the use of logger(1) - and you should use it more wisely to get appropriate log messages under /var/log
BTW, your PATH is ridiculously too long. Such a long PATH is messy (and might slow down your shells) and could be a security risk; my recommendation would be to have a much shorter one (perhaps as short as $HOME/bin:/usr/local/bin:/bin:/usr/bin) and add appropriate symlinks or scripts in e.g. $HOME/bin/ or /usr/local/bin/ using explicit program paths.
Notice that sudo could be used in a crontab job (but that is often unwise) and then probably should be configured in /etc/sudoers ; perhaps you should prefer /bin/su (see su(1)...) in some shell script.
Read also more about setuid. Sometimes it is wiser to write in C a wrapper setuid- program using it (with setreuid(2)), but be careful (you could open huge security holes by mistake).
Read also Advanced Linux Programming (freely downloadable, a bit old) then syscalls(2) to understand better how Linux works internally. You need to have a better and more clear picture of your system in your head.
I have a very simple script that works from the command line.
#!/bin/bash
reboot
When I put a call to execute the script into root users crontab -e using the following format it does not run. It does run the first two commands, just that last one is giving me grief. I have no MTA installed as I do not need it.
*/10 * * * * service jwtpay restart
0 3 * * * bash /root/backup/mongo.backup.s3.sh kickass /root/backup >/dev/null 2>&1
0 */3 * * * bash /root/reboot.sh >/dev/null 2>&1
What am I missing?
Maybe the script is not executable... Since you use root's crontab why call the binary via a script and not the binary itself? Use the full path to the binary. It may vary on your system. Find out where it is with which reboot.
0 */3 * * * /sbin/reboot
Don't forget to restart the cron daemon, after changeing the crontab.
I'm using a Raspberry Pi for a status display, but for whatever reason it gets incredabbly sluggish after a day or so of running so I wanted to reboot it every day so I setup a cron job to do that every morning at 8:50. But, it doesn't seem to be working. Is there anything special about using cron to do a reboot?
This is my crontab for the root user:
# m h dom mon dow command
50 8 * * * shutdown now -r >> /var/log/cron.log
0,30 * * * * date >> /var/log/cron.log
The second line works just fine, but I can't seem to get the restart command to work. It doesn't even output anything to the log.
Try using the fully specified path to shutdown. date may be in the PATH in roots cron environment, /sbin may not be looked up.
You need to edit the root user crontab
sudo crontab -e
then..
50 8 * * * reboot
Save and exit.
I'm trying to use a cronjob to run a ruby script (Using Rails3 runner) with the following Cronjobs:
#!/bin/bash
0-59 * * * * echo 'script test'
# Begin Whenever generated tasks for: test1
* * * * * /bin/bash -l -c '/home/administrator/test1/script/rails runner /home/administrator/test1/app/create_flag.rb >> /home/administrator/test1/test.log 2>&1'
# End Whenever generated tasks for: test1
test1 is the name of the Rails3 project folder.
the "echo 'script test'" was added as a test, but neither seems to be executing. I'm currently using Ubuntu 10.04 LTS.
Have I written the cronjob incorrectly?
Crontab file is not a shell script. So you don't need #!/bin/bash at the beginning of the file. Plus, spaces there are suspicious. Try something like this:
SHELL=/bin/bash
MAILTO=administrator#localhost
BASH_ENV=/home/administrator/.bash_profile
* * * * * /home/administrator/test1/script/rails runner /home/administrator/test1/app/create_flag.rb >> /home/administrator/test1/test.log 2>&1'
Plus, make sure you call crontab -e as administrator to edit the crontab file.
You need to specify the user which runs the commands (you can see the format here. Also the echo will output 'script test' to what? If you want a test try doing a touch on a file, so you can physically see the action of the cron job.
Cron does not use your user environment, so it will not have the same path set that you have. This means that you should use absolute paths for commands.