Cron unexpected behaviour when date changes - linux

I've a cron instance executing in a embedded device in a ELINOS4 environment. This device have a problem, I think related to battery, which changes the system date.
For the embedded application is not a problem because the app resynchornize the date. But for cron daemon affects its scheduler causing to programm next execution far in the future. Executing cron with flags I get this logs:
[3933] TargetTime=1359121500, sec-to-wait=60
...
[3933] spool dir mtime unch, no load needed.
[3933] tick(45,13,24,0,5) user [root:0:0:...] cmd="/etc/logrotate /etc/logrotate.conf"
[3933] TargetTime=1359121560, sec-to-wait=1130199663
[3933] sleeping for 1130199663 seconds
I've tried to change manually the date, but cron doesn't detect this change (it's sleeping https://stackoverflow.com/a/4141239).
One quick hack is to modify the source code of cron, but does a better solution exist?
Thanks in advance

Aside from the obvious "fix your hardware", the immediate suggestion would be to have a daemon that checks the time, and if it sees it jump back (or forward?) more than a few seconds, restart crond (and any other process that may use this sort of method to determine "next time to wake up").

Related

Infinte loop vs cron job

I have an uploader service which needs to run every 5minutes and it definitely finished within 5 minutes so there are never two parallel session.
Wondering what would be a good strategy to run this, either to schedule this as a cron job on host or start a go program with infinite loop which execute the program and sleeps(Golang: Implementing a cron / executing tasks at a specific time)
If your task is...
On Unix
Stand alone
Periodic
Has an acceptable startup time
cron will be better than rolling your own scheduler just for the one service. It will guarantee the process will always run at the correct time and has rudimentary error reporting. There's no need to add a watchdog in case your infinite loop has an error, cron will run the process again in 5 minutes.
If cron is insufficient, look into other job schedulers before rolling your own.
I have an uploader service which needs to run every 5minutes and it definitely finished within 5 minutes so there are never two parallel session.
These are famous last words. I would suggest adding in some form of locking. For example, write your PID to a file in /var/run and check if that process is running. There's even a little pidfile library for Go.
Take a look on Systemd, you can execute a script with timers and set max execution time for the script.
https://wiki.archlinux.org/index.php/Systemd/Timers

Linux job scheduler launching a script 2 hours after it terminates

I have a script that runs unknown period of time that depends on its input. It can run one hour when little data available, or it can run for 8 hours if much data is to be processed.
I need to run it periodically, particularly 2 hours after previous run was completed.
Is there an utility to do that?
Use 'at' instead of 'cron' and at the end of your script add:
at now +2 hours $*
This means that each occurrence is chained - so if it terminates abnormally the next instance won't be scheduled - but I don't think there's a more robust solution without adding a lot of code/complexity.
I don't like the at solution proposed, so here another solution:
Use cron to launch your every two hours
Upon startup, your application(*) checks if there's a pidfile.
2.1 if it is present, then there may be another instance running: read contents of the file (pid) and see if that pid is the pid of an existing process, a zombie process or something else. If it is the pid of a running, existing process, then exit. If it is the pid of a zombie process then the previous job ended unexpectedly and then you have to delete the pidfile and go to step 3. Otherwise.
After deleting pidfile, you create a new one and put your pid into it. Then proceed to do your job.
*: In order not to add complexity, this application i cited could also be a simple wrapper that spawns your code using exec.
This solution can also be scripted quite easily.
Hope it helps,
SnoopyBBT
If it looks complicated, here is another, dirtier solution:
while true ; do
./your_application
sleep 7200
done
Hope this helps,
SnoopyBBT

How to pause a php script launched with crontab?

I have a PHP scraper running every night on a very large site. Crontab launches the script at 2am and pkill it at 7am. Now I am concerned that brutally killing the script might result in data loss. Let's say that crontab calls the script off while the script is busy writing my scraped data into the database, then the next day the database will refuse that last/first record because it is already present (even if not completely).
Is there any way I can freeze the script with crontab? (That is, without adding a sleep() to my script)
Let's say that crontab calls the script off while the script is busy writing my scraped data into the database
That would be a problem, since you will run into some transaction timeout or something, if you stop your process externally. A better way would be to let the script halt/pause on its own. You could for example define some marker file that is checked by the script periodically so that the script can halt/pause in a controlled way.
Having one large cronjob that can't be interrupted is usually a sign of bad design for a number of reasons.
Most notably, you can't interrupt the run for no reason whatsoever or you'll end up with corrupted data. This can become a big problem in case you have an unexpected power loss or server crash.
Also, it doesn't scale. If you need to process more data, you can't scale it to multiple servers. If you have run times of a few hours now, you may end up exhausting a complete server very soon.
I would recommend to seriously rethink the functionality of this cronjob and restructure it so you have a number of smaller tasks that are queued up somewhere. (It can even be the database.) You could then mask the SIGINT and SIGTERM signals when processing a single task and check the received signals in between tasks. This will allow you to notify the process using either of the aforementioned and have it shut down gracefully.
That being said, things do break and servers do crash. I also urge you to work out plans for data recovery in case the cronjob breaks down while working on something.

How to handle overtime crons

Suppose if i have cron tasks running every minute. And if each time, that task takes more than one minute to run, what will happen. Will the next cron wait for the first cron or will it run without any checks.
I want to run a cron task every minute and I don't over lapping cron tasks like that in case of a long running task/situation.
please help.
It depends on what you run. If it's your own script, you can implement a locking/lock checking mechanism to avoid running duplicates.
But that's not cron's job.
Yes, cron will go ahead and start your 1+ minute-running process every minute until something crashes.
You'll want to put a lock of some sort into your job if you can to basically do this at start-up:
if not get_lock()
print "Another process is running"
exit
This, of course, assumes that you own the code running. If you're running a command that you didn't code, then I'd recommend building a shell wrapper that implements the above pseudocoded logic where get_lock() will see if another process like this one is running.
As others have mentioned, CRON will run your script every minute regardless of whether another instance of your script is still running.
If you want to avoid this and don't fancy implementing your own locking mechanism then you could try using a CRON alternative called The Fat Controller which is a daemon that will continually re-run scripts. You can optionally specify an interval between runs and also optionally specify a maximum execution time so if a script goes AWOL then it can be killed.
There's some use cases and more information on the website:
http://fat-controller.sourceforge.net/

Advanced Scheduled Process/Task Manager - Linux

Need some advice, I'm after a decent process/task manager for Ubuntu.
Basically I have a few scripts/programs which I want to run as long running processes, but I want to shut them down at various periods (say over the weekend or every day for a few hours). During the time that the process needs to be up and crashes, I would like it so that the task scheduler will automatically restart the process.
SO for example, I want to run program X between 9:00-17:00 every day. If the process is still running it should be killed at 17:00. If the process crashes between 9AM and 5PM then the process should be automatically restarted.
Are there any easy to use tools which can do this? I would like to avoid having to manage PID files and having cron jobs which do the start and stop...
Any thing anyone recommends? Any advice appreciated!
Cheers.
I do not know if a tool exists for this, but except if you have many interactive tasks, it really does not a that big issue to manage for a few jobs :
1) You can start your cronjobs whenever you like thanks to the crontab,
2) You can insert a "commit suicide" within these scripts under a time condition for example.
# your script doing things
# Then it commit suicide
if [ your_condition ];then
kill $$
fi
Please note that if you want to allow users login only at certain periods of time, then it's a different question.

Resources