[mythtv-users] Way to tell BE came up after power fail?

Craig Huff huffcslists at gmail.com
Thu Oct 24 20:53:32 UTC 2013


I left out relevant details in an attempt to focus on the immediate
problem.  From your comments, it seems I should have provided more
details.  Here's the long story.

My system shuts down when not actively recording or viewing and
automatically wakes up when new recordings are about to begin, or it is
time to grab an update from SchedulesDirect.  If the power fails or gets
shut off while the system is shutdown (shutdown to state S4 or S5), I have
it set up in the BIOS to automatically restart the system.  This is
necessary to re-establish the ACPI/APM wakeup alarm so it will wake when it
is time to do something useful.  Unfortunately, I also have the system set
up to stay up when it is awakened off-schedule on the presumption that a
user has turned it on to watch something or do work on it.  Manual
intervention is then needed (and presumed to be available) to unlock
mythbackend so the system will shutdown after the user is finished.  Hence
my search for a way to deal with the automatic power restoration bootup and
cause an automatic shutdown after re-establishing the ACPI/APM wakeup time.

A second issue that occurs when the power has been removed is that the
(IguanaWorks) USB IR transceiver's device file fails to get created,
although the subdirectory for it _does_ get created in /dev (as part of the
udev rule executed when the transceiver is recognized).  The udev rule is
not what causes the device file to get created and I have not been
successful at finding what does.  The udev rule only creates the directory
that the device file gets created in.  I have searched through all the logs
in /var/log, scanned dmesg, etc., and found no clues to explain this
quirk.  A long time ago, for other reasons, I modified the init .conf
script for the transceiver's daemon to wait until after udev processes and
reports the usb-device-added event.  The daemon _does_ get started both in
normal circumstances and in this problem situation.

I have not had any luck determining how the device file gets created in the
subdirectory -- it's not part of the udev rule that creates the
subdirectory -- and there's no indication in any of the logs that anything
is different when the power has been off vs. when the power has been
maintained.

In summary, this isn't about dealing with system crashes due to power
failure, but rather it's about dealing with a quirk that occurs on reboot
after power failure.  This is the reason I was looking for something that
would tell me that the system was wakened automatically by the BIOS on
restoration of power.

Based on the inputs so far, it seems the best approach available to me is
to create another init .conf script that will wait until the daemon has
been started and then check to see if the device file exists.  I may have
to put some kind of delay into this new script if the daemon gets started
before the device file gets created under normal circumstances.  At the
point where I think the device file should exist and still doesn't, I can
"yank the chain" and shut the system down, trusting that the wakeup alarm
will bring it up again when there is _real_ work to do.  I just was hoping
for a more elegant solution that wouldn't run the risk of getting stuck in
an infinite reboot loop.

I suppose it's a "good thing" that the device file consistently fails to
get created when the power has been removed since this seems to be the only
way I can tell that it is okay (and further, necessary!) to shutdown in an
orderly fashion because A) the system needs to be rebooted to get the
device file created so the desktop tuner adapters can get channel info
blasted to them and B) the system probably doesn't need to be on at the
current time anyway.  Even if the system does have work to do, reason A)
means a reboot is needed so the system can function correctly.  Either the
wakeup alarm will just bring it right back up or a recording will be missed
that would have been missed anyway if the boot-on-power-restore hadn't been
enabled in the first place.

Now you have all the gory details.  Any further suggestions would be
welcomed.

--
Craig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20131024/6ae88ee7/attachment.html>


More information about the mythtv-users mailing list