Chronological Inconsistencies

In the previous post, I indicated how to schedule a job using Back In Time at any desired time of day using Gnome’s Scheduled Tasks utility. However, I also noted that the resulting cron job would not run if the machine was not turned on at the time when the job was scheduled to be run. A companion program, anacron*, is used to circumvent this little problem and ensure that the daily backup job is run once each day, irrespective of its actual scheduled time.

* Anacron takes its name from anachronism which is indicative of an event occurring out of its normal, chronological order

Anacron is installed as part of the Ubuntu 10.04 distro and so is ready and waiting to be assigned the daily backup task. The implementation is also quite straightforward. One places a script file that contains instructions to run Back In Time in the folder /etc/cron.daily. The basic idea is that, when the machine is booted, anacron is run automatically and, in turn, runs all the scripts in cron.daily. Since our daily backup script is located in this folder, Back In Time now runs to create our daily backup.

Of course, the devil is in the details:

(1) The machine must be powered up at least once during any given day for that day’s backup task to run.

(2) The script file has to be properly constructed (more on this – much more! – later) or the backup job will fail. Clearly, we need to test the system before relying on it for data backup.

(3) Anacron runs only once each day so testing the system might be construed to be a long-term proposition; however, with a little cunning we can work around this issue.

My first attempt at creating the necessary script file was simply to include the command to run Back In Time that was used by Scheduled Tasks, as follows:

#!/bin/sh
# Run Back In Time
nice -n 19 /usr/bin/backintime –backup-job

The result was – nothing. No new snapshot was created in Back In Time and the script failed – as they say – “silently”, so there was no clue as to the problem.

Various postings on the web suggested that my script file needed to specify some environment variables such as:

SHELL=/usr/bin
PATH=/usr/bin:/bin:/usr/local/bin

or that the command line for backintime needed to include “/usr/bin/” for nice as well as for backintime giving:

/usr/bin/nice -n 19 /usr/bin/backintime –backup-job

Now, one trick to testing all these suggestions is to work around anacron’s propensity to only run the cron.daily scripts once per day. Otherwise, one has to wait until the next day to test a new version of a script, which is quite a problem if you have several variants on a given script to test!

However, it turns out that anacron sets a flag to indicate that the cron.daily scripts have been run on any given day. It does this by entering the date on which the scripts were run in the file /var/spool/anacron/cron.daily. This is a simple text file with the date in the form 20120909. Consequently, in order to “trick” anacron into running the cron.daily scripts multiple times each day, we simply have to edit the contents of this file using:

sudo gedit /var/spool/anacron/cron.daily

and change the stored date to yesterday’s date (e.g. change 20120909 to 20120908). Now, when the machine is rebooted, anacron checks the flag, sees that it last “ran” the cron.daily scripts on the previous day, and proceeds to initiate the script files. In this way, we can run the test script every few minutes, rather than having to wait a whole day!

One further tweak in this regard is that, by default, anacron waits for five minutes before running the cron.daily scripts. The second trick to further speed up the testing process is to edit the file /etc/anacrontab using the command:

sudo gedit /etc/anacrontab

In particular, we find the line that runs (run-parts) the cron.daily scripts:

1    5    cron.daily    nice run-parts –report /etc/cron.daily

The initial “1” indicates that run-parts is to be run once each day while the subsequent “5” provides a 5-minute delay of this job following anacron’s initiation when the machine boots. Simply by changing the “5” to a “1” on this line, we can have our script run just one minute after boot-up:

1    1    cron.daily    nice run-parts –report /etc/cron.daily

So, now we have a fairly efficient test bed. We can make a change to our script file, change the date stored in /var/spool/anacron/cron.daily, reboot the machine, and our “daily” script will run immediately.

And, a good job too. Unfortunately, adding the environment variables, and including more /usr/bin/’s had no effect on Back In Time’s silent refusal to create a new snapshot.

Clearly, we need some additional tools to troubleshoot our specific problem…

References:

What is Anacron?
http://anacron.sourceforge.net/

Using cron to automate maintenance
http://www.ibm.com/developerworks/aix/tutorials/au-usingcron/section4.html

CronHowto – How Anacron is Arranged
https://help.ubuntu.com/community/CronHowto#How_Anacron_is_Arranged

Automate Linux with Cron and Anacron
http://tuxradar.com/content/automate-linux-cron-and-anacron

Using anacrontab in ubuntu (backintime as example)
http://salonen.wordpress.com/2009/05/31/using-anacrontab-in-ubuntu/

Advertisements
This entry was posted in anacron, Applications, Backup, Bash script, cron and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s