Mailing List Archive

init.d
After I get ACPI shutdown and wakeup working I'd like my database back-up
to run right before shut down. Does anyone have a script written to do
this, that they could share? TIA Daryl
Re: init.d [ In reply to ]
On Fri, 11 Sep 2020 15:20:59 -0400, you wrote:

>After I get ACPI shutdown and wakeup working I'd like my database back-up
>to run right before shut down. Does anyone have a script written to do
>this, that they could share? TIA Daryl

Getting things to happen during shutdown is a fraught business. The
fundamental problem is that there are times when you need shutdown to
happen immediately, and anything that hinders that is a big problem.
For example, you have a hard drive that is making funny noises and you
need to get it shut down before you lose all its data. Or you have a
thunder storm passing over and you need to shut down and unplug all
your electronics before a nearby lightning strike kills them all. Or
you are rebooting your MythTV box to allow a kernel upgrade to happen,
and you have only 10 minutes between recordings do to that. Then the
shutdown backup runs and takes 10 minutes (mine does) and the next
recording starts before the shutdown happens.

In your case, you should be thinking of doing the database backup once
a day as usual, and preventing the initiation of an automatic shut
down while the backup is running, rather than starting the backup as
part of the shutdown process. So just let the backups happen as usual
as part of the anacron jobs in /etc/cron.weekly or /etc/cron.daily.
Then in your script that initiates shutdown, detect if the backup job
is running (or any anacron job is running) and wait for it to
complete. To detect if an anacron job is running, just check if the
program "anacron" is running. So I would add something like this to
the start of the shutdown script:

while pgrep anacron /dev/null 2>&1; do
# anacron is running - wait for a while.
sleep 10
done

If the normal time that anacron jobs are run is missed because the
system is shut down, the next time it wakes up, anacron will be run
automatically and the jobs will be run. Missed anacron jobs are run
shortly after the wakeup time - I think it is about a minute later.
The short delay is so as to not overload the system by running anacron
jobs at the same time as things that run when the PC wakes up.

In modern Ubuntu systems (since systemd), anacron is run by the
systemd units "anacron.service" and "anacron.timer". The
"anacron.timer" unit sets when it is run from a timer, and that unit
runs "anacron.service" every time the timer is triggered. The
"anacron.service" unit is run from the timer and usually also at
startup. You can configure how it all works. If you want
anacron.service to be run at startup, then you have to have the
anacron.service unit enabled:

sudo systemctl enable anacron

That is the default. If you do not want anacron.service to run at
startup, but only from the timer, disable anacron.service:

sudo systemctl disable anacron

Similarly, you can enable or disable anacron.timer:

sudo systemctl enable anacron.timer
sudo systemctl disable anacron.timer

For normal operation both units should be enabled, but for 24/7
servers, I prefer to disable anacron.service so that anacron jobs do
not get run immediately after a reboot that is done after midnight.
Maintenance on 24/7 servers is often done after midnight and it is a
big pain if anacron suddenly runs a whole set of jobs and you have to
wait for them to finish before you can reboot your server again!

However, anacron in Ubuntu has a bug with its default configuration.
When the change to systemd happened, whoever was responsible for
converting anacron to be run by systemd thought that anacron was
responsible for running the /etc/cron.hourly jobs, and therefore
anacron needed to be run every hour. In fact, the /etc/cron.hourly
jobs are run by cron, not anacron. But in Ubuntu 18.04 and earlier,
anacron.timer is set to run every hour, which is wrong and can cause
some significant complications. To fix that, I create a systemd
override file to run anacron.timer only once a day at a more normal
time like 05:30. To do that run this command:

sudo systemctl edit anacron.timer

That will open your default editor. Paste this text into the file:

[Unit]
Description=Trigger anacron at 05:30.

[Timer]
OnCalendar=
OnCalendar=05:30
RandomizedDelaySec=0s
Persistent=true

Save the file and exit, then run this:

sudo systemctl daemon-reload

Some time between Ubuntu 18.04 and Ubuntu 20.04, a change has been
made to anacron.timer to this:

[Unit]
Description=Trigger anacron every hour

[Timer]
OnCalendar=*-*-* 07..23:30
RandomizedDelaySec=5m
Persistent=true

[Install]
WantedBy=timers.target

Which I believe means that (despite the "Description" comment) anacron
will be run at 30 minutes past the hour, but only between 07:30 and
23:30. I am not sure why that was done, but it is also wrong and
still should be overridden as above.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: init.d [ In reply to ]
On Fri, Sep 11, 2020 at 10:14 PM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Fri, 11 Sep 2020 15:20:59 -0400, you wrote:
>
> >After I get ACPI shutdown and wakeup working I'd like my database back-up
> >to run right before shut down. Does anyone have a script written to do
> >this, that they could share? TIA Daryl
>
> Getting things to happen during shutdown is a fraught business. The
> fundamental problem is that there are times when you need shutdown to
> happen immediately, and anything that hinders that is a big problem.
> For example, you have a hard drive that is making funny noises and you
> need to get it shut down before you lose all its data. Or you have a
> thunder storm passing over and you need to shut down and unplug all
> your electronics before a nearby lightning strike kills them all. Or
> you are rebooting your MythTV box to allow a kernel upgrade to happen,
> and you have only 10 minutes between recordings do to that. Then the
> shutdown backup runs and takes 10 minutes (mine does) and the next
> recording starts before the shutdown happens.
>
> In your case, you should be thinking of doing the database backup once
> a day as usual, and preventing the initiation of an automatic shut
> down while the backup is running, rather than starting the backup as
> part of the shutdown process. So just let the backups happen as usual
> as part of the anacron jobs in /etc/cron.weekly or /etc/cron.daily.
> Then in your script that initiates shutdown, detect if the backup job
> is running (or any anacron job is running) and wait for it to
> complete. To detect if an anacron job is running, just check if the
> program "anacron" is running. So I would add something like this to
> the start of the shutdown script:
>
> while pgrep anacron /dev/null 2>&1; do
> # anacron is running - wait for a while.
> sleep 10
> done
>
> If the normal time that anacron jobs are run is missed because the
> system is shut down, the next time it wakes up, anacron will be run
> automatically and the jobs will be run. Missed anacron jobs are run
> shortly after the wakeup time - I think it is about a minute later.
> The short delay is so as to not overload the system by running anacron
> jobs at the same time as things that run when the PC wakes up.
>
> In modern Ubuntu systems (since systemd), anacron is run by the
> systemd units "anacron.service" and "anacron.timer". The
> "anacron.timer" unit sets when it is run from a timer, and that unit
> runs "anacron.service" every time the timer is triggered. The
> "anacron.service" unit is run from the timer and usually also at
> startup. You can configure how it all works. If you want
> anacron.service to be run at startup, then you have to have the
> anacron.service unit enabled:
>
> sudo systemctl enable anacron
>
> That is the default. If you do not want anacron.service to run at
> startup, but only from the timer, disable anacron.service:
>
> sudo systemctl disable anacron
>
> Similarly, you can enable or disable anacron.timer:
>
> sudo systemctl enable anacron.timer
> sudo systemctl disable anacron.timer
>
> For normal operation both units should be enabled, but for 24/7
> servers, I prefer to disable anacron.service so that anacron jobs do
> not get run immediately after a reboot that is done after midnight.
> Maintenance on 24/7 servers is often done after midnight and it is a
> big pain if anacron suddenly runs a whole set of jobs and you have to
> wait for them to finish before you can reboot your server again!
>
> However, anacron in Ubuntu has a bug with its default configuration.
> When the change to systemd happened, whoever was responsible for
> converting anacron to be run by systemd thought that anacron was
> responsible for running the /etc/cron.hourly jobs, and therefore
> anacron needed to be run every hour. In fact, the /etc/cron.hourly
> jobs are run by cron, not anacron. But in Ubuntu 18.04 and earlier,
> anacron.timer is set to run every hour, which is wrong and can cause
> some significant complications. To fix that, I create a systemd
> override file to run anacron.timer only once a day at a more normal
> time like 05:30. To do that run this command:
>
> sudo systemctl edit anacron.timer
>
> That will open your default editor. Paste this text into the file:
>
> [Unit]
> Description=Trigger anacron at 05:30.
>
> [Timer]
> OnCalendar=
> OnCalendar=05:30
> RandomizedDelaySec=0s
> Persistent=true
>
> Save the file and exit, then run this:
>
> sudo systemctl daemon-reload
>
> Some time between Ubuntu 18.04 and Ubuntu 20.04, a change has been
> made to anacron.timer to this:
>
> [Unit]
> Description=Trigger anacron every hour
>
> [Timer]
> OnCalendar=*-*-* 07..23:30
> RandomizedDelaySec=5m
> Persistent=true
>
> [Install]
> WantedBy=timers.target
>
> Which I believe means that (despite the "Description" comment) anacron
> will be run at 30 minutes past the hour, but only between 07:30 and
> 23:30. I am not sure why that was done, but it is also wrong and
> still should be overridden as above.
>
> As usual a very detailed and interesting reply, which I will study
further. The reason I thought I'd like the DB_backup run before shutdown
is, my past problems have occured after an evening of recordings, which
don't get backed up until the system turns on, and the system doesn't turn
on because something borked.

Yes anacron is enabled here.
Re: init.d [ In reply to ]
>
>
>> As usual a very detailed and interesting reply, which I will study
> further. The reason I thought I'd like the DB_backup run before shutdown
> is, my past problems have occured after an evening of recordings, which
> don't get backed up until the system turns on, and the system doesn't turn
> on because something borked.
>

It‘s interesting to read about the anacron approach. I use a
script-approach and that seems to work since years. But I had no need to
restore or recover the database due to errors.

I use mythwelcome. When the system is idle then a shutdown script will be
started. It runs checks (is mythshutdown safe? Is there a samba connection
left? ...), runs fstrim and a database backup once a day and shuts down the
backend machine.

But when I use the Shutdown menu option on the mythwelcome screen, then
mythshutdown is called directly - my script will not be used. So a quick
shutdown is possible as well.

If this seems to be interesting for your use case I would fiddle out the
script and send it to you.

Kind Regards
Jens
Re: init.d [ In reply to ]
On Sat, Sep 12, 2020 at 6:40 AM Swanseasurfing <swanseasurfing@gmail.com>
wrote:

>
>>> As usual a very detailed and interesting reply, which I will study
>> further. The reason I thought I'd like the DB_backup run before shutdown
>> is, my past problems have occured after an evening of recordings, which
>> don't get backed up until the system turns on, and the system doesn't turn
>> on because something borked.
>>
>
> It‘s interesting to read about the anacron approach. I use a
> script-approach and that seems to work since years. But I had no need to
> restore or recover the database due to errors.
>
> I use mythwelcome. When the system is idle then a shutdown script will be
> started. It runs checks (is mythshutdown safe? Is there a samba connection
> left? ...), runs fstrim and a database backup once a day and shuts down the
> backend machine.
>
> But when I use the Shutdown menu option on the mythwelcome screen, then
> mythshutdown is called directly - my script will not be used. So a quick
> shutdown is possible as well.
>
> If this seems to be interesting for your use case I would fiddle out the
> script and send it to you.
>
> Kind Regards
> Jens
>
>
> Yes, Jens this sounds very interesting to me, I would very much appreciate
your script, thank you.
Re: init.d [ In reply to ]
>
>
>>
>> Yes, Jens this sounds very interesting to me, I would very much
> appreciate your script, thank you.
>
> Hi Daryl,

I fiddled out the scripts, translated them and created a minimum
documentation. Have a look here:
https://github.com/jims-code/MythTV-Helpers

Before you use one of the scripts you should follow these steps:
- edit script and change parameters to your own needs (e.g. logfile name)
- ensure that the logfile specified in the parameters exists and that the
user mythtv has write permissions
- ensure that programs used in the scripts are installed (e.g. wakeonlan,
feh)
- make script executable (chmod)

Let me know if you got the hint that you needed to get rid of your MythTV
problem.

Have fun
Jens


>
Re: init.d [ In reply to ]
On Thu, Sep 17, 2020 at 4:53 PM Swanseasurfing <swanseasurfing@gmail.com>
wrote:

>
>>>
>>> Yes, Jens this sounds very interesting to me, I would very much
>> appreciate your script, thank you.
>>
>> Hi Daryl,
>
> I fiddled out the scripts, translated them and created a minimum
> documentation. Have a look here:
> https://github.com/jims-code/MythTV-Helpers
>
> Before you use one of the scripts you should follow these steps:
> - edit script and change parameters to your own needs (e.g. logfile name)
> - ensure that the logfile specified in the parameters exists and that the
> user mythtv has write permissions
> - ensure that programs used in the scripts are installed (e.g. wakeonlan,
> feh)
> - make script executable (chmod)
>
> Let me know if you got the hint that you needed to get rid of your MythTV
> problem.
>
> Have fun
> Jens
>
>>
>>
Thanks Jens, yes I got the hint, and normally I have no problem,
occasionally, during rerun season, when I use Kodi more, a recording drive
will unmount, which defies the logic of everyone consulted to date.?!
I have the ACPI working well now, so I'm toying with the idea of having the
"checklogin.sh" call your script, that is if my programming son can find
some time to look it over.

Mythtv Rocks! Thanks to all the devs and everyone on this list! Daryl