I have a pretty good understanding how the crontab is formatted but have no idea how to write the cronjob entry to execute a script every 30 hours, is it even possible? Thanks.

Hello,

I might be very wrong but I doubt that it's possible using cron. The range for the hour statement is 0-23 as far as I know. What you might do is write your own script and use the at command, don't know if that will work but if one can say:
then it would be logical that you could say
since at works with a sort of timestamp when the at command was timed and calculates from there, where cron references to a time within a period (does this makes sence?).

If you could write your script with the at command (haven't tried it), then you could easily make it 'rewrite' itself every 30 hours when it ran.

Kind regards,

Eric

I think using a combination of the sleep command in a script is the answer.

Using at and submitting a new job from inside the script itself is a good idea. There is just a downside to take in account: if the machine is switched off for some reason at the time the job is scheduled, the at daemon will run the "expired" job at the successive boot up (this issue is discussed in a recent thread, here). If this happens the regular 30-hours scheduling is delayed and maybe this is an unwanted effect.

Another solution can be the following:
This script records a reference time in seconds since epoch, which is the time at which the job is scheduled. The if/then construct checks if the current time is greater than or equal to the reference time and if the condition is matched it executes the code AND edits itself to update the reference time by 30 hours (it adds 108000 seconds to the reference time).

In this way you can run this job every 10 hours, using a crontab entry like
and the block of code inside the if/then will be executed alternatively 1 time every 3. That is every 30 hours. Choose carefully the first reference time, that will be the actual time at which the cron job is executed for the first time, and the trick is done!

Edit: just thinking about the crontab entry... maybe even better is to run the script at fixed hours, so you can establish the starting reference time more precisely. Suppose you run the first job at midnight. Then adding 30 hours make the job to run at 6 of the next day, then at 12 of the day after and so on. Hence an entry like this
should be enough and you can easily determine the starting reftime using for example

Hi,

Thanks colucix for pointing out the downside, that's something I didn't take into account.

Kind regards,

Eric

Hi Eric,

unfortunately re-reading this thread after your reply... I realized the same downside is in the crontab method suggested: if the computer is down at the scheduled time, the script is not updated. I have to rethink about it. Thanks.

Kind regards,
Alex

Hello Alex,

Wouldn't it be possible to write output to a file when the script was executed successfully and then check the outputfile for the last runtime? If the outputfile isn't present or out of date then it's safe to assume that the script was not executed, and then a procedure has to be launched to reset the reference time. Of course the first time the outputfile has to be generated by hand since it will be checked when first run.

Just thinking out wild, but that might solve the problem no?

Kind regards,

Eric

Yes, it might solve the problem. You have just to store the file somewhere and (over)write the date into it every time the script is executed (or better when the block of code inside an if/then construct is executed).

Here is an alternative, which simply checks the current date without reference time (except for unix time) and without external files:
The computed time at the beginning of the script is the integer of the number of seconds since epoch expressed in hours. Here we take advantage of the fact that bash does not manage floating point numbers, hence the result of the division is a truncated integer. The integer is necessary to take into account the 1 or more seconds delay in the execution of the script (in respect of the exact scheduled time).

Then it simply checks if the number of hours since epoch is exactly a multiple of 30. The only and mandatory constrain is that you have to start the job at a time (since epoch) which is already a multiple of 30 hours.

The next (based on CET time zone, not UTC) useful start times are:
if the machine uses UTC the starting point have to be recalculated.

In my example the crontab entry would be something like:
To avoid the aforementioned constrain, we can try to simply add (or substract) an offset from the computed time. Once the offset is carefully determined, we can start our cron job at every hour and minute, at our pleasure.