mrw;594326 Wrote: > @gharris999 > > A thought occurs to me: > Should sleep_inhibit register for the "system will now sleep" call-back > and shut itself off on that event as well as timer expiry ? > I'm not sure how the timer survives system sleep, and there might be > unexpected results if sleep_inhibit is still running when the system > next wakes.Presumably, the system won't sleep while the timer is waiting > since the 'NoSleep' assertion isn't released until after the timer has fired. But what you suggest would be a fail-safe. The only unexpected result if the timer never did fire would be an 'orphaned' instance of sleep-inhibit idling in the background that would have to be manually killed. No biggie, as far as I can anticipate. It's not like it would be chewing up memory or CPU cycles.
mrw;594326 Wrote: > As a longer term project it might even undertake the "on sleep" task > that SleepWatcher is currently doing for you...It's hard for me to imagine > being able to improve on SleepWatcher. Even if I were to extend it by adding sockets processing code so that the daemon could communicate with SBS via the CLI, it hardly seems like it would be worth the effort. I don't imagine that the results would be any better than what can be accomplished with scripts. I think it would be useful, however, to include a setup script with SrvrPowerCtrl that would configure SleepWatcher to make the srvrpowerctrl setwakealarm request on sleep. Making that easy to set up will be the only way that this feature will ever get used by more than 1 or 2 people. mrw;594326 Wrote: > I'm not sufficiently familiar with SrvrPowerCtrl [1]. My off the cuff > thought would be to go with two separate plug-ins and keep the > functionality and coding split. Presumably the plug-ins could talk to > each other if some small communication were to be useful ? Plugins can easily communicate with each other via the $client->request mechanism or by calling Slim::Control::Request::executeRequest() which is the same thing. It's basically intra-SBS CLI. mrw;594326 Wrote: > I do use it to reboot my Plug computer from time to time. I am planning > to see if I can get it to initiate a few other system admin > tasks.SrvrPowerCtrl's EOD function needs will probably fill your needs. EOD needs one final tweak in it's functioning, I think. It ought to be such that, if the EOD idle-timeout is set to 0 and if a custom script is set as the EOD action, and if the custom script, among other chores, reboots the system, SrvrPowerCtrl ought to be smart upon on reboot to execute the selected combo-box action as a "secondary" action. So...your custom script does lots of chores and ends by rebooting the system. SrvrPowerCtrl, when it finishes initializing, realizes that it's still in the EOD period and when thus immediately suspends the system, or whatever action is selected in the combobox. SrvrPowerCtrl already treats the EOD action as an alarm and schedules a system-wakeup if the EOD action is a custom script. As it stands, EOD mostly works this way...except it doesn't currently take that "secondary" action. It's just smart enough to know that it shouldn't endlessly repeat the custom script upon reboot. But until I code that final last tweak, set the EOD period from, say 2:00 am to 2:05 am, set the idle time-out to 0 and set the action to your own custom script. Remember, you'll probably need to give the squeezeboxserver user passwordless permissions to run the script in /etc/sudoers. -- gharris999 ------------------------------------------------------------------------ gharris999's Profile: http://forums.slimdevices.com/member.php?userid=115 View this thread: http://forums.slimdevices.com/showthread.php?t=48521 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
