<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>