<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/24/2013 04:53 PM, Craig Huff
wrote:<br>
</div>
<blockquote
cite="mid:CAO0hLGr2dFqi6e55prJUYP=C=f3xHdR6bD5Y+0x99cajANbk-g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">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.<br>
<br>
</div>
<div class="gmail_extra">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.<br>
<br>
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.<br>
<br>
</div>
<div class="gmail_extra">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.<br>
<br>
</div>
<div class="gmail_extra">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.<br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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.<br>
<br>
</div>
<div class="gmail_extra">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.<br>
<br>
</div>
<div class="gmail_extra">Now you have all the gory details. Any
further suggestions would be welcomed.<br>
<br>
--<br>
</div>
<div class="gmail_extra">Craig.<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mythtv-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a>
<a class="moz-txt-link-freetext" href="http://www.mythtv.org/mailman/listinfo/mythtv-users">http://www.mythtv.org/mailman/listinfo/mythtv-users</a>
</pre>
</blockquote>
<br>
I have an IguanaWorks device and it randomly fails to initialize
after a reboot. I use a simple script in my startup and also in the
channel change script and when starting teh frontend.<br>
<br>
<a class="moz-txt-link-freetext" href="http://code.google.com/p/mythtv-scripts/source/browse/trunk/install/opt/mythtv/bin/lirc_drivercheck.sh">http://code.google.com/p/mythtv-scripts/source/browse/trunk/install/opt/mythtv/bin/lirc_drivercheck.sh</a><br>
<br>
It checks the Iguana driver as well as lirc and starts them if they
are not running<br>
<br>
Peter<br>
</body>
</html>