[mythtv-users] anacron time change after upgrade to Ubuntu 18.04

Stephen Worthington stephen_agent at jsw.gen.nz
Thu Nov 8 03:21:53 UTC 2018


On Wed, 07 Nov 2018 14:23:17 -0700, you wrote:

>On Wednesday, November 7, 2018 9:33:59 AM MST Jerry wrote:
>> On Wed, Nov 7, 2018 at 7:20 AM Jim Abernathy <jfabernathy at gmail.com> wrote:
>> > I think the answer is to remove my database backup and optimize commands
>> > from /etc/cron.daily and put them back in my $HOME directory.
>> > 
>> > Then create a new entry in the /etc/crontab that just executes those
>> > commands when I want them to run.
>> 
>> +1 for simplicity.
>> 
>> I like /etc/crontab myself.  It's easier to put each user's jobs in one
>> place (I'm the only one who schedules jobs).  It's simple to copy that file
>> and save it somewhere just in case, and it's easier when upgrading a
>> machine.  I use regular crontab when I have to on some embedded machines,
>> but I try to use /etc/crontab whenever possible.

In Ubuntu and most distros, all files in /etc are preserved during
upgrades.  If there is a clash between a file you have modified and a
new version of the file from a package, then you get asked what to do
about it.  In the cron.{hourly,daily,weekly,monthly} files, if you are
adding your own jobs, all you need to do is give them different names
from the package files and they will be preserved forever.  If you
edit the /etc/crontab file, you will get one of those "modified file"
situations every time you upgrade the cron package.  The right place
to put your own ordinary cron jobs is *not* /etc/crontab.  Put a new
file, with a name that will not clash, in /etc/cron.d.

>I second that. Just 1 file, stay away from /etc/cron.{hourly,daily,monthly}, 
>let the system use them. Use FOO=bar settings near the top of the file to 
>define the paths to things that will be run and $FOO on the entry lines. Use 
>separator lines by hour and some formatting to make the whole thing easy to 
>read. Don't be afraid to use spaces and tabs to line things up nicely.

Cron.hourly jobs are run from cron, not anacron.

>In addition I automatically comment out everything in /etc/anacrontab ever 
>since Fedora started making it actually do something some ways back. It's 
>still useful to catch up with cron jobs after a reboot though, AFAICT.

There is a fatal flaw in using cron for running regular jobs.  If
something is scheduled in cron, and for whatever reason cron is not
working at the scheduled time (eg the PC is asleep, powered down, in
the middle of a power cut, locked up due to a kernel bug, ...), then
the scheduled cron jobs will not be run.  That is why anacron was
invented.  So if you are running your MythTV box so that it goes to
sleep when it is not busy, it will likely never do the vital database
check and backup jobs if they are run from cron.  Even worse, if you
are using an SSD and not using the "discard" option in fstab, the TRIM
job for the SSD will never be run if the PC is asleep at that time.
Using anacron instead of cron is vital if you are using a laptop, as
they are normally off or asleep most of their lives.

Another problem with cron is that it runs the jobs at the specified
time, so if the database check job runs for too long, the database
backup job can be started before the check job is finished.  That
would thrash the database badly and likely cause failed recordings and
who knows what other problems.  As your database grows, both of those
jobs take longer, so if you use cron, you will forever have to be
checking that they are not taking too long.  With anacron, the jobs
are run sequentially (that is what the -s option on anacron does).

Cron does run the jobs in cron.hourly sequentially though - but not
jobs in its crontab tables - they are run at the time specified, in
parallel with each other.  So cron.hourly jobs may be run in parallel
with jobs in crontab.


More information about the mythtv-users mailing list