Ok so I have a cron that I need to run every 30 seconds.
Here is what I have:
*/30 * * * * /bin/bash -l -c 'cd /srv/last_song/releases/20120308133159 && script/rails runner -e production '\''Song.insert_latest'\'''
It runs, but is this running every 30 minutes or 30 seconds?
Also, I have been reading that cron might not be the best tool to use if I run it that often. Is there another better tool that I can use or install on Ubuntu 11.04 that will be a better option? Is there a way to fix the above cron?
You have */30
in the minutes specifier - that means every minute but with a step of 30 (in other words, every half hour). Since cron
does not go down to sub-minute resolutions, you will need to find another way.
One possibility, though it's a bit of a kludge(a), is to have two jobs, one offset by 30 seconds:
# Need these to run on 30-sec boundaries, keep commands in sync.
* * * * * /path/to/executable param1 param2
* * * * * ( sleep 30 ; /path/to/executable param1 param2 )
You'll see I've added comments and formatted to ensure it's easy to keep them synchronised.
Both cron
jobs actually run every minute but the latter one will wait half a minute before executing the "meat" of the job, /path/to/executable
.
For other (non-cron
-based) options, see the other answers here, particularly the ones mentioning fcron
and systemd
. These are probably preferable assuming your system has the ability to use them (such as installing fcron
or having a distro with systemd
in it).
If you don't want to use the kludgy solution, you can use a loop-based solution with a small modification. You'll still have to manage keeping your process running in some form but, once that's sorted, the following script should work:
#!/bin/env bash
# Debug code to start on minute boundary and to
# gradually increase maximum payload duration to
# see what happens when the payload exceeds 30 seconds.
((maxtime = 20))
while [[ "$(date +%S)" != "00" ]]; do true; done
while true; do
# Start a background timer BEFORE the payload runs.
sleep 30 &
# Execute the payload, some random duration up to the limit.
# Extra blank line if excess payload.
((delay = RANDOM % maxtime + 1))
((maxtime += 1))
echo "$(date) Sleeping for ${delay} seconds (max ${maxtime})."
[[ ${delay} -gt 30 ]] && echo
sleep ${delay}
# Wait for timer to finish before next cycle.
wait
done
The trick is to use a sleep 30
but to start it in the background before your payload runs. Then, after the payload is finished, just wait for the background sleep
to finish.
If the payload takes n
seconds (where n <= 30
), the wait after the payload will then be 30 - n
seconds. If it takes more than 30 seconds, then the next cycle will be delayed until the payload is finished, but no longer.
You'll see that I have debug code in there to start on a one-minute boundary to make the output initially easier to follow. I also gradually increase the maximum payload time so you'll eventually see the payload exceed the 30-second cycle time (an extra blank line is output so the effect is obvious).
A sample run follows (where cycles normally start 30 seconds after the previous cycle):
Tue May 26 20:56:00 AWST 2020 Sleeping for 9 seconds (max 21).
Tue May 26 20:56:30 AWST 2020 Sleeping for 19 seconds (max 22).
Tue May 26 20:57:00 AWST 2020 Sleeping for 9 seconds (max 23).
Tue May 26 20:57:30 AWST 2020 Sleeping for 7 seconds (max 24).
Tue May 26 20:58:00 AWST 2020 Sleeping for 2 seconds (max 25).
Tue May 26 20:58:30 AWST 2020 Sleeping for 8 seconds (max 26).
Tue May 26 20:59:00 AWST 2020 Sleeping for 20 seconds (max 27).
Tue May 26 20:59:30 AWST 2020 Sleeping for 25 seconds (max 28).
Tue May 26 21:00:00 AWST 2020 Sleeping for 5 seconds (max 29).
Tue May 26 21:00:30 AWST 2020 Sleeping for 6 seconds (max 30).
Tue May 26 21:01:00 AWST 2020 Sleeping for 27 seconds (max 31).
Tue May 26 21:01:30 AWST 2020 Sleeping for 25 seconds (max 32).
Tue May 26 21:02:00 AWST 2020 Sleeping for 15 seconds (max 33).
Tue May 26 21:02:30 AWST 2020 Sleeping for 10 seconds (max 34).
Tue May 26 21:03:00 AWST 2020 Sleeping for 5 seconds (max 35).
Tue May 26 21:03:30 AWST 2020 Sleeping for 35 seconds (max 36).
Tue May 26 21:04:05 AWST 2020 Sleeping for 2 seconds (max 37).
Tue May 26 21:04:35 AWST 2020 Sleeping for 20 seconds (max 38).
Tue May 26 21:05:05 AWST 2020 Sleeping for 22 seconds (max 39).
Tue May 26 21:05:35 AWST 2020 Sleeping for 18 seconds (max 40).
Tue May 26 21:06:05 AWST 2020 Sleeping for 33 seconds (max 41).
Tue May 26 21:06:38 AWST 2020 Sleeping for 31 seconds (max 42).
Tue May 26 21:07:09 AWST 2020 Sleeping for 6 seconds (max 43).
If you want to avoid the kludgy solution, this is probably better. You'll still need a cron
job (or equivalent) to periodically detect if this script is running and, if not, start it. But the script itself then handles the timing.
(a) Some of my workmates would say that kludges are my specialty :-)
If you are running a recent Linux OS with SystemD, you can use the SystemD Timer unit to run your script at any granularity level you wish (theoretically down to nanoseconds), and - if you wish - much more flexible launching rules than Cron ever allowed. No sleep
kludges required
It takes a bit more to set up than a single line in a cron file, but if you need anything better than "Every minute", it is well worth the effort.
The SystemD timer model is basically this: timers are units that start service units when a timer elapses.
So for every script/command that you want to schedule, you must have a service unit and then an additional timer unit. A single timer unit can include multiple schedules, so you normally wouldn't need more than one timer and one service.
Here is a simple example that logs "Hello World" every 10 seconds:
/etc/systemd/system/helloworld.service
:
[Unit]
Description=Say Hello
[Service]
ExecStart=/usr/bin/logger -i Hello World
/etc/systemd/system/helloworld.timer
:
[Unit]
Description=Say Hello every 10 seconds
[Timer]
OnBootSec=10
OnUnitActiveSec=10
AccuracySec=1ms
[Install]
WantedBy=timers.target
After setting up these units (in /etc/systemd/system
, as described above, for a system-wide setting, or at ~/.config/systemd/user
for a user-specific setup), you need to enable the timer (not the service though) by running systemctl enable --now helloworld.timer
(the --now
flag also starts the timer immediately, otherwise, it will only start after the next boot, or user login).
The [Timer]
section fields used here are as follows:
OnBootSec - start the service this many seconds after each boot.
OnUnitActiveSec - start the service this many seconds after the last time the service was started. This is what causes the timer to repeat itself and behave like a cron job.
AccuracySec - sets the accuracy of the timer. Timers are only as accurate as this field sets, and the default is 1 minute (emulates cron). The main reason to not demand the best accuracy is to improve power consumption - if SystemD can schedule the next run to coincide with other events, it needs to wake the CPU less often. The 1ms in the example above is not ideal - I usually set accuracy to 1 (1 second) in my sub-minute scheduled jobs, but that would mean that if you look at the log showing the "Hello World" messages, you'd see that it is often late by 1 second. If you're OK with that, I suggest setting the accuracy to 1 second or more.
As you may have noticed, this timer doesn't mimic Cron all that well - in the sense that the command doesn't start at the beginning of every wall clock period (i.e. it doesn't start on the 10th second on the clock, then the 20th and so on). Instead is just happens when the timer ellapses. If the system booted at 12:05:37, then the next time the command runs will be at 12:05:47, then at 12:05:57, etc. If you are interested in actual wall clock accuracy, then you may want to replace the OnBootSec
and OnUnitActiveSec
fields and instead set an OnCalendar
rule with the schedule that you want (which as far as I understand can't be faster than 1 second, using the calendar format). The above example can also be written as:
OnCalendar=*-*-* *:*:00,10,20,30,40,50
Last note: as you probably guessed, the helloworld.timer
unit starts the helloworld.service
unit because they have the same name (minus the unit type suffix). This is the default, but you can override that by setting the Unit
field for the [Timer]
section.
More gory details can be found at:
Arch Linux Wiki page about SystemD timers which gives a very good overview of the topic, with examples.
man systemd.timer
man systemd.time
man systemd.service
man systemd.exec
{ ruby main.rb & sleep 10 ;} && ... && ruby main.rb
. You see, in the last iteration I don't call sleep
-- I thought that I need to inline the loop like this because I had the "process is still running"
error. The error message is gone but it still skips the second iteration I don't why. Still debugging.
You can't. Cron has a 60 sec granularity.
* * * * * cd /srv/last_song/releases/20120308133159 && script/rails runner -e production '\''Song.insert_latest'\''
* * * * * sleep 30 && cd /srv/last_song/releases/20120308133159 && script/rails runner -e production '\''Song.insert_latest'\''
&&
instead of ( ; )
.
&&
operator short-circuits, so the next command in the chain is not executed if the previous one failed.
Cron's granularity is in minutes and was not designed to wake up every x
seconds to run something. Run your repeating task within a loop and it should do what you need:
#!/bin/env bash
while [ true ]; do
sleep 30
# do what you need to here
done
while [ true ]
cause you to have lots of instances of the same script, since cron will start a new one every minute?
sleep $remainingTime
where remainingTime is 30 minus the time the job took (and cap it at zero if it took > 30 seconds). So you take the time before and after the actual work, and calculate the difference.
No need for two cron entries, you can put it into one with:
* * * * * /bin/bash -l -c "/path/to/executable; sleep 30 ; /path/to/executable"
so in your case:
* * * * * /bin/bash -l -c "cd /srv/last_song/releases/20120308133159 && script/rails runner -e production '\''Song.insert_latest'\'' ; sleep 30 ; cd /srv/last_song/releases/20120308133159 && script/rails runner -e production '\''Song.insert_latest'\''"
Cron job cannot be used to schedule a job in seconds interval. i.e You cannot schedule a cron job to run every 5 seconds. The alternative is to write a shell script that uses sleep 5
command in it.
Create a shell script every-5-seconds.sh using bash while loop as shown below.
$ cat every-5-seconds.sh
#!/bin/bash
while true
do
/home/ramesh/backup.sh
sleep 5
done
Now, execute this shell script in the background using nohup
as shown below. This will keep executing the script even after you logout from your session. This will execute your backup.sh shell script every 5 seconds.
$ nohup ./every-5-seconds.sh &
backup.sh
takes 1.5 seconds to run, it will execute every 6.5 seconds. There are ways to avoid that, for example sleep $((5 - $(date +%s) % 5))
You can check out my answer to this similar question
Basically, I've included there a bash script named "runEvery.sh" which you can run with cron every 1 minute and pass as arguments the real command you wish to run and the frequency in seconds in which you want to run it.
something like this
* * * * * ~/bin/runEvery.sh 5 myScript.sh
Use watch:
$ watch --interval .30 script_to_run_every_30_sec.sh
$ watch --interval .10 php some_file.php
? or watch
works only with .sh files ?
--interval .30
will not run twice a minute. I.e watch -n 2 "sleep 1 && date +%s"
it will increment every 3s.
watch
was designed for terminal use, so - while it can work without a terminal (run with nohup
then logout) or with a fake terminal (such as screen
) - it has no affordances for cron-like behavior, such as recovering from failure, restarting after boot, etc'.
Currently i'm using the below method. Works with no issues.
* * * * * /bin/bash -c ' for i in {1..X}; do YOUR_COMMANDS ; sleep Y ; done '
If you want to run every N seconds then X will be 60/N and Y will be N.
YOUR_COMMANDS
to YOUR_COMMANDS &
, so that the command is launched to the background, otherwise, if the command takes more than a fraction of a second - it will delay the next launch. So with X=2 and Y=30, if the command takes 10 seconds - it will launch on the minute and then 40 seconds later, instead of 30. Kudus to @paxdiablo.
/bin/bash -c
part (including the argument quotes) the script only runs every minute, ignoring the iteration (in my case X=12
and Y=5
).
process already running
. Probably because the sleep
needs some miliseconds more to die. It would be nice to not call the last sleep
, i.e. for example call them only 5 times for 1 minute with 10 sec pauses.
Use fcron (http://fcron.free.fr/) - gives you granularity in seconds and way better and more feature rich than cron (vixie-cron) and stable too. I used to make stupid things like having about 60 php scripts running on one machine in very stupid settings and it still did its job!
in dir /etc/cron.d/
new create a file excute_per_30s
* * * * * yourusername /bin/date >> /home/yourusername/temp/date.txt
* * * * * yourusername sleep 30; /bin/date >> /home/yourusername/temp/date.txt
will run cron every 30 seconds
You can run that script as a service, restart every 30 seconds
Register a service
sudo vim /etc/systemd/system/YOUR_SERVICE_NAME.service
Paste in the command below
Description=GIVE_YOUR_SERVICE_A_DESCRIPTION
Wants=network.target
After=syslog.target network-online.target
[Service]
Type=simple
ExecStart=YOUR_COMMAND_HERE
Restart=always
RestartSec=10
KillMode=process
[Install]
WantedBy=multi-user.target
Reload services
sudo systemctl daemon-reload
Enable the service
sudo systemctl enable YOUR_SERVICE_NAME
Start the service
sudo systemctl start YOUR_SERVICE_NAME
Check the status of your service
systemctl status YOUR_SERVICE_NAME
Crontab job can be used to schedule a job in minutes/hours/days, but not in seconds. The alternative :
Create a script to execute every 30 seconds:
#!/bin/bash
# 30sec.sh
for COUNT in `seq 29` ; do
cp /application/tmp/* /home/test
sleep 30
done
Use crontab -e
and a crontab to execute this script:
* * * * * /home/test/30sec.sh > /dev/null
write one shell script create .sh file
nano every30second.sh
and write script
#!/bin/bash
For (( i=1; i <= 2; i++ ))
do
write Command here
sleep 30
done
then set cron for this script crontab -e
(* * * * * /home/username/every30second.sh)
this cron call .sh file in every 1 min & in the .sh file command is run 2 times in 1 min
if you want run script for 5 seconds then replace 30 by 5 and change for loop like this: For (( i=1; i <= 12; i++ ))
when you select for any second then calculate 60/your second and write in For loop
Have a look at frequent-cron - it's old but very stable and you can step down to micro-seconds. At this point in time, the only thing that I would say against it is that I'm still trying to work out how to install it outside of init.d but as a native systemd service, but certainly up to Ubuntu 18 it's running just fine still using init.d (distance may vary on latter versions). It has the added advantage (?) of ensuring that it won't spawn another instance of the PHP script unless a prior one has completed, which reduces potential memory leakage issues.
Thanks for all the good answers. To make it simple I liked the mixed solution, with the control on crontab and the time division on the script. So this is what I did to run a script every 20 seconds (three times per minute). Crontab line:
* * * * 1-6 ./a/b/checkAgendaScript >> /home/a/b/cronlogs/checkAgenda.log
Script:
cd /home/a/b/checkAgenda
java -jar checkAgenda.jar
sleep 20
java -jar checkAgenda.jar
sleep 20
java -jar checkAgenda.jar
I just had a similar task to do and use the following approach :
nohup watch -n30 "kill -3 NODE_PID" &
I needed to have a periodic kill -3 (to get the stack trace of a program) every 30 seconds for several hours.
nohup ... &
This is here to be sure that I don't lose the execution of watch if I loose the shell (network issue, windows crash etc...)
The Linux Cron time-based scheduler by default does not execute jobs with shorter intervals than 1 minute. This config will show you a simple trick how to use Cron time-based scheduler to execute jobs using seconds interval. Let’s start with basics. The following cron job will be executed every minute:
* * * * * date >> /tmp/cron_test
The above job will be executed every minute and insert a current time into a file /tmp/cron_test. Now, that is easy! But what if we want to execute the same job every 30 seconds? To do that, we use cron to schedule two exactly same jobs but we postpone the execution of the second jobs using sleep command for 30 seconds. For example:
* * * * * date >> /tmp/cron_test
* * * * * sleep 30; date >> /tmp/cron_test
Run in a shell loop, example:
#!/bin/sh
counter=1
while true ; do
echo $counter
counter=$((counter+1))
if [[ "$counter" -eq 60 ]]; then
counter=0
fi
wget -q http://localhost/tool/heartbeat/ -O - > /dev/null 2>&1 &
sleep 1
done
60
should be a 30
, you might want to move that wget
inside the if
statement, otherwise it's executed every second. In any case, I'm not sure how this is any better than just a single sleep 30
. If you were monitoring the actual UNIX time rather than your counter, it would make a difference.
Through trial and error, I found the correct expression: */30 * * ? * * * This translates to every 30 seconds. Reference: https://www.freeformatter.com/cron-expression-generator-quartz.html They have provided the expression for running every second: * * * ? * * * */x is used to run at every x units. I tried that on the minute's place and viola. I'm sure others have already found this out, but I wanted to share my Eureka moment! :D
Success story sharing
fcron
andsystemd
answers (no point duplicating the info in this answer). If available,systemd
is preferable even with the minimal extra setup required.