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

[R. G. Newbury]

On 11/02/2013 02:13 PM, Craig Huff wrote:
> On Wednesday, October 30, 2013, R. G. Newbury wrote:
>
>     1)
>     A two-stage scripted system,
>     Main part runs under cron every minute/5 minutes whatever. The cron
>     runs a script which calls 'uptime > /home/mythtv/uptimer'.
>
>     The other part is a line in /etc/rc.d/rc.local (or some other
>     initscript) which renames /home/mythtv/uptimer to uptimer-old on boot.
>     If you have a 'old' the system has rebooted, and you can tell how
>     long ago from the new uptimer.
>
>
>     2)
>     Or something like this, using cron OR an init-script:
>     The cron first writes uptime to /home/mythtv/uptimer
>     The cron then attempts to copy /home/mythtv/uptimer to
>     /tmp/uptimer/uptimer
>
>     After a reboot /tmp/uptimer will not exist and an error will be raised.
>     The error condition requires operator action to clear.
>
>     Post-notification handling is left to the student as an exercise!
>
>
>     Geoff
>
>
>
> Geoff-
>
> Thanks for the idea. Unfortunately, in my case (OP), the problem arises
> when the system is down on purpose -- nothing to do -- and power is
> removed.  In this case, my system is configured to wake up when power is
> restored.  This had two issues: how to tell the system came up due to a
> power interruption as opposed to a user wanting to do something
> off-schedule (e.g. Watch something), and get the IR Transmitter/Receiver
> configuration fixed (it consistently fails the first time up after power
> interruption).  My solution to both problems is not robust in that it
> depends on continued misbehavior that most likely will get fixed in some
> newer version of the O/S or LIRC SW.
>
> What would be ideal would be a way to find out programmatically from the
> BIOS that the system was brought up on power restore, not the "On"
> switch, WOL, etc.
>
> In any case thanks for taking the time to make the suggestion.  It may
> give someone else an idea how to solve a variant of the situation.
>

Well, a variant of the first uptimer cron will tell you that a re-start 
took place. Adding a 'date > /tmp/restart' line to rc.local will tell 
you the real time when that took place. Presumably you already know when 
you have scheduled restarts... plus or minus a minute, that will tell 
you that an unscheduled restart occurred.

If you use a real file to record startup, the existence of a restart 
file could toggle a 'rm' and reboot. That would work around your IR problem,

Of course, someone wandering in and restarting things, *looks* exactly 
like a power cycle. Despite the different problems which a UPS (hah!) 
can create, using one can reduce 'false positives' on restarts. Any 
power outage which over-runs the run-time of a UPS will likely make 
itself known to you by other means. So that an unscheduled restart will 
almost assuredly be user initiated.

Thinking outside the box, wouldn't suspend/hibernate (plus a UPS) 
provide the same results, assuming that suspend/hibernate does not also 
give rise to the 'needs 2 restarts' problem.

Respecting the 2 restarts: what happens if you cold restart the second 
time? I suspect that you probably warm reset the second time, and things 
work thereafter. This suggests to me that you might have timing issues 
with the hardware.

Geoff














-- 
              R. Geoffrey Newbury			
            Mandamus Publishing Inc.
               www.mandamus.ca