Crontab reboot job reboot multiple times instead of once - cron

I am trying to schedule my debian jessie machine to shutdown at 9:00 p.m. every 3 days. I currently use a cronjob:
00 21 */3 * * root bash /home/pi/scripts/reboot.sh
where reboot.sh is:
sudo reboot
The machine shuts down on schedule but what is strange is that it just keeps rebooting for several times. how am I able to get rid of this issue. is this related to maybe the RTC clock no have enough time to update itself and so the cron job still thinks the time is still 9... I really doubt this.. any help

its better to use the internal command shutdown instead of using the script. shutdown now shuts the computer and -r flag is for reboot system. you can also pass specific time instead of now like shutdown -r 11:00.
For now you can use
shutdown -r now

Related

Setting up a cronjob on Google Compute Engine

I am new to setting up cronjobs and I'm trying to do it on a virtual machine in google compute engine. After a bit of research, I found this StackOverflow question: Running Python script at Regular intervals using Cron in Virtual Machine (Google Cloud Platform)
As per the answer, I managed to enter the crontab -e edit mode and set up a test cronjob like 10 8 * * * /usr/bin/python /scripts/kite-data-pull/dataPull.py. I also checked the system time, which was in UTC, and entered the time according to that.
The step I'm supposed to take, as per the answer, is to run sudo systemctl restart cron which is throwing an error for me:
sudo systemctl restart cron
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Any suggestions on what I can do to set up this cronjob correctly?
Edit a cron jobs with crontab -e and inset a line:
* * * * * echo test123 > /your_homedir_path/file.log
That will write test123 every minute into file.log file.
Then do tail if and wait a couple minutes. You should see test123 lines appearing in the file (and screen).
If it runs try running your python file but first make your .py file executable with "chmod +x script.py"
Here you can find my reply to similar question.

Running bash script 10 minutes after the system start

I'm trying to run a bash script 10 minutes after my system startup and on every reboot. I was planning to the #reboot of crontab, but I'm not sure of two things
Whether it will run on the first system start or only on reboot.
How to delay the run by 10 minutes after the reboot.
What expression would suit my situation the best? Please note that I can't run 'at' or system timer to accomplish this as both are not accessible to us. I'm working on the RHEL 7..
I would just sleep 600 at the beginning of your reboot script. Sure, there's probably a more "expert" way of doing it, but it'll work.
I think your question may be more appropriate on the Unix and Linux stack exchange, because I found two answers over there which directly address your question:
https://unix.stackexchange.com/questions/57852/crontab-job-start-1-min-after-reboot
Basically you can always just add sleep 600 to the beginning of your cronjob invocation.
As to whether you should be running a cronjob vs an init script:
https://unix.stackexchange.com/questions/188042/running-a-script-during-booting-startup-init-d-vs-cron-reboot
There are a handful of subtle differences, but basically, your cron #reboot will run each time the system starts and may be more easy to manage as a non-root user.
rc-local.service would be better for your needs on a EL7 system.
systemctl status rc-local.service
● rc-local.service - /etc/rc.d/rc.local Compatibility
Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor preset: disabled)
Active: inactive (dead)
You need to put your script that can run with any amount of delay inside the file, /etc/rc.d/rc.local, e.g.,
sleep 600 && /usr/local/bin/myscript.sh
OR you can put delay inside the script.
# Give exe permission to the local script as well as `rc.local`
chmod a+x /usr/local/bin/myscript.sh
chmod a+x /etc/rc.d/rc.local
# Enable the service. Note the service name has a `-` compared `.` in the file.
systemctl enable rc-local.service

Cron scheduled task ignored

I have set a specific cronjob (crontab -e), but it doesn't works like I thought. I don't get what's wrong.
Here is what I do (root cron):
#reboot /path/to/my_script.sh start
25 18 * * * halt
The first line as expected is running my_script.sh, but when time comes for the server to shutdown, nothing happen. Is the #reboot option made to work alone?
There is no option in cron to run at shutdown. #reboot is meant to run the script on start
If you want to run a script at shutdown, you need to write an initd script and register it for the shutdown run level. The standard runlevel for halt is 0, the run level for restart is 6. I've verified this for Debian, Gentoo and Redhat systems but it seems to be true across *NIX systems. Check this for more info.

About system time in a bash script

I'm starting work on a bash script that will shutdown my computer at a certain time of day, but I'm not really sure what all specifically needs to go into that. Could someone post an example of how they would do it?
If you want to shut down at 22:15 every day, be root, run crontab -e, then add
15 22 * * * shutdown -h 5
on a line by itself.
Then save. At 22:15 every day, you will get a warning that the system will shut down in 5 minutes, and five minutes later, true to its word, it shuts down. If you want to abort the shutdown, run shutdown -c as root after the warning.

cron job fails to restart services

I have a simple script that stops and starts the services (of Oracle Hyperion)
#!bin/ksh
/path/to/dir/stop.sh
sleep 1200
/path/to/dir/start.sh
I have scheduled it for every night and it does run, however there is an issue with database connectivity afterwards. But when i run stop.sh and start.sh manually, there is no such issue. Obviously the job had not run completely.
Here's the output from crontab -l
00 02 * * * /export/home/oracle/scheduled_restart.sh
Could someone please advise on the problem? Thanks.
The usual cause for cron jobs to differ from command line during execution of the exact same code is environment, specifically the variables like ORACLE_SID, TWO_TASK, LD_LIBRARY_PATH, and so on.
Assuming the oracle user own the crontab:
When a job is run by crond it does the equivalent of su oracle, not su - oracle. Try doing something to ensure that the command sources everything the oracle user would normally source during login.
To see what is going on:
/export/home/oracle/scheduled_restart.sh && set > /tmp/my_variables.txt
You do not need the /bin/sh if the /export/home/oracle/scheduled_restart.sh file is executable.
It should have a shebang on line 1. ex: #!/bin/ksh for korn shell or whatever shell you use.

Resources