[mythtv-users] crontab vs. anacron from a mythtv perspective

[Stephen Worthington]

On Fri, 9 Nov 2018 07:30:42 -0500, you wrote:

>Not a problem, but a discussion. In working with Stephen Worthington on 
>figuring out why database maintenance task changed their runtime after 
>switching to Ubuntu 18.04, I got to thinking.
>
>Yes, I know that me thinking is always dangerous, but here goes.
>
>1.  There must be some reason that the Ubuntu folks set the anacron 
>daily stuff to run just after midnight. Not sure if I change it back to 
>7:35, as in Ubuntu 16.04, if that fixes my problem but breaks theirs. Or 
>will break it in the near future.

My thought about what happened was that Ubuntu are trying to move most
things over to using systemd - that was an aim for 18.04.  So they
assigned someone to do tidy ups of various small things that were not
using systemd but should be easily changed to systemd - such as
anacron.  The person doing the changes did not properly understand
anacron and looked at the cron.{hourly,daily,weekly} directories and
thought that cron.hourly was run by anacron like the other two, when
in fact it is not.  So they thought that anacron needed to be run
hourly, did that, and then did not test it at all properly.  I am
fairly sure that running anacron hourly is a bug.

>2.  Manually editing /etc/crontab is frowned on and your changes can get 
>overwritten by a system upgrade.

Yes, but that is what the /etc/cron.d directory fixes.  Packages put
files in /etc/cron.d instead of editing /etc/crontab.  The root user
can do the same safely, as long as you choose a name for the file that
will not be used by a package.  A pretty easy way to do that is to use
your initials as the start of the file name.

>3.  The conclusion I've reached is that if I setup my specific 
>maintenance jobs use 'sudo crontab -e' then my maintenance jobs will 
>continue to run correctly after a system upgrade. Apparently, 'crontab 
>-e' creates/edits each users individual crontab and leaves the system 
>crontab alone.

For user cron jobs, crontab -e (no sudo) is the right way to do it.
These user crontab files are stored here:

/var/spool/cron/crontabs

in a file with the same name as the user.

For a root crontab file, sudo crontab -e works and creates a file
/var/spool/cron/crontabs/root, the same way as for other user
crontabs.

>I found a good explanation at: 
>https://www.digitalocean.com/community/tutorials/how-to-schedule-routine-tasks-with-cron-and-anacron-on-a-vps

That explanation seems to be Fedora style, rather than Ubuntu.

>Now of course, my solution only works on backend's that always run and 
>never sleep.

Which is why you should let anacron do what it was designed to do, and
put daily jobs in /etc/cron.daily and so on.  Then if those jobs get
missed because the box was not running at the time, they will then get
run 5 minutes after the box is started again.  There are some things
that it is important to have happen like that - just take a look at
your /etc/cron.daily and /etc/cron.weekly for examples.  Such as
logrotate and fstrim.  And for a laptop, there is a high likelihood
that the laptop will rarely be running when the maintenance jobs are
scheduled for, so using anacron is the only way to ensure that the
maintenance jobs will ever be run.

If you try and manually schedule daily, weekly and monthly jobs, you
also run into the problem of how long each job will take, and how much
that time may grow over the years.  So you initially schedule job1 at
07:30 and it takes up to 10 minutes, so you schedule job2 for 07:40.
But a year later, job1 is taking 12 minutes, and since they both are
heavy database users, having them both running at once causes the
machine to thrash so badly that it takes a couple of hours to get it
to shut down.  I have seen this exact example - and working out what
caused it was quite a pain too.  So it is best to avoid awful things
like that by using anacron and cron.daily so that however long the
jobs take to run, they will only be executed in sequence, one by one.

Or you can use a cron job, but get it to execute a list of jobs using
the same mechanism that anacron does - create a directory to put the
jobs in, then get the cron job to use run-parts to run all the files
in that directory in order, one by one.  But it is easier to just use
cron.daily.  And if you do it yourself, you run the risk that if one
of the jobs hangs and the rest are never executed, the next day there
will be another cron job that gets created and does the same thing.
With anacron, I think anacron checks to see if it is already running
and does not run more jobs if it is already doing something.  So your
machine will not grind to a halt with 20 hung jobs using all the RAM.

There are lots of "gotchas" with cron jobs that anacron is the fix
for.  Unless you really need something to run at a specific time (eg
turn off the kids Internet access at 21:00), then you should use
anacron.  And even then, you need to think carefully - a cron job to
turn on the kids Internet access again at 07:30 should really be an
anacron job, as I am sure that if you rebooted at about 07:30 and
their turn on cron job missed its trigger time, you would find
yourself in hot water.  So you might even need both a cron job and an
anacron job for some things.  If I wanted to do that, I would probably
create a /etc/anacron.d directory that worked like /etc/cron.d.
Running cron jobs is unfortunately a complicated business.  We have
not even covered the problem of which cron jobs should be run first
and all the interactions that involves.

>Thought?
>
>Jim A