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

Jim Abernathy jfabernathy at gmail.com
Fri Nov 9 14:46:45 UTC 2018


On 11/9/18 9:05 AM, Stephen Worthington wrote:
> 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

All your points are valid and apply in a wide range of applications.

I'm thinking more simplistic for my application which is a battery 
backed up mythtv backend server. With either method, I will not miss a 
daily run of database maintenance.

It may be that I've used crontab since AT&T shipped System 5 release 4 
Unix on 5.25" floppies, so I'm more familiar with it. I'm also looking 
at installation steps to accomplish the simple task of setting up 
mythtv-backup and optimize_mythdb. Maybe after systemd is more stable 
and it becomes second nature, I'll view it as easy. Right now I'm 
struggling with the logic behind the commands to accomplish all this in 
systemd vs. cron.

Thanks for the discussion.  I'm learning a lot about stuff I've ignored 
for too long.

Jim A





More information about the mythtv-users mailing list