Announce: Beta version of SvrPowerControl

[gharris999]

I was refering to the Restart Server action, not Restart Squeezecenter (although it maybe common to both - I haven't checked)

OK, let me check this out. I'll be dealing with "other stuff" for the next day or two. But I'll try to get on this. I have a copy of MS Visual Studio 2008 on order. Hopefully, before the end of the month, I'll have a working vista machine that I can do development on to make sure SCPowerTool operates on Vista and Win7 too.

[agillis]

This module works great for me. I added it to VortexBox so VortexBox users can use it easily.

[Wirrunna]

Gordon,
I have both Lazy Search and Server Power Control installed and suspect that Server Power Control shuts down my server before the lazification process has finished if I kick off a "clear and rescan everything" before going to bed at night.
I've posted in Stuart's Lazy Search thread and hopefully you and he can sort this out.

[gharris999]

Gordon,
I have both Lazy Search and Server Power Control installed and suspect that Server Power Control shuts down my server before the lazification process has finished if I kick off a "clear and rescan everything" before going to bed at night.
I've posted in Stuart's Lazy Search thread and hopefully you and he can sort this out.

Tell me more about Lazy Search. Does "lazification" need to happen every time you scan for new? Every time you clear & scan?

Any plugin can set and clear SrvrPowerCtrl blocks via the CLI without having to worry about whether SrvrPowerCtrl is installed or not. If SrvrPowerCtrl isn't there, the cli call is harmless and does nothing.

E.G.

#Prevent untimely suspends, etc.. 
my $blockcode = $client->execute(['srvrpowerctrl', 'setblock', 'reason_for_blocking', 'block_owner']);

#my long running process...
#...
#...

#Unblock suspends, etc...
$client->execute(['srvrpowerctrl', 'clearblock', $blockcode, 'block_owner']);

Wrapping a long-ish process in those set & clear block cli requests will prevent SrvrPowerCtrl from interrupting a process by shutting down / suspending / etc.

[Wirrunna]

Gordon, Lazy Search has been modified to set and clear SrvrPowerCtrl blocks, tested OK (details in the Lazy Search thread), thank you.
One thing I have noticed is that SrvrPowerCtrl does not put an entry in the Server Log when it initiates a shutdown. I believe that SrvrPowerCtrl should log an entry for the actions that it initiates.

[gharris999]

Gordon, Lazy Search has been modified to set and clear SrvrPowerCtrl blocks, tested OK (details in the Lazy Search thread), thank you.
One thing I have noticed is that SrvrPowerCtrl does not put an entry in the Server Log when it initiates a shutdown. I believe that SrvrPowerCtrl should log an entry for the actions that it initiates.

It depends on which level of logging you have selected for SrvrPowerCtrl in SC Settings->Advanced->Logging. The default level for SrvrPowerCtrl right now is "Error" and only errors get logged with that setting. Changing it to "Info" or above will start to put more and more data into the server log. At "Debug", SrvrPowerCtrl is probably way too chatty for most folks. Try the "Info" setting and see if that is more to your taste. I'll be happy to consider changing the default log setting from "Error" to "Info" if you think there is utility in this.

PS: on windows, SCPowerTool.exe can keep its own log. Just add the "--log" parameter onto the SCPowerTool cmd line. The log file, by default, is called "SCPowerTool.log" and will be in the same directory as SCPowerTool.exe.

[Wirrunna]

I've set SrvrPowerCtrl logging to info.
I just like to see an entry in a log somewhere if a running application causes a system shutdown. Harks back to 30 years in the computing game.

[gharris999]

I've set SrvrPowerCtrl logging to info.
I just like to see an entry in a log somewhere if a running application causes a system shutdown. Harks back to 30 years in the computing game.

I agree that this should be logged *somewhere*. You are running Windows, yes? What do you see in the system Event Viewer? SCPowerTool ought to be leaving system messages there, so I believe I've got that case covered already. Would you be willing to check your event viewer and confirm that it IS being logged?

On Linux systems, I suppose I ought to modify the default shutdown command line so that the *reason* for the shutdown ends up in /var/log/messages. But, as far as I can tell, pm-suspend and pm-hibernate don't take an optional "reason" parameter, so I don't currently know how to put a message into /var/log/messages on suspend or hibernate.

[epoch1970]

But, as far as I can tell, pm-suspend and pm-hibernate don't take an optional "reason" parameter, so I don't currently know how to put a message into /var/log/messages on suspend or hibernate.

If you set pm-utils for debug, it won't log to syslog. There is a specific trace file in /var/log. Perhaps it is intended that syslog can be one of the services stopped before suspend ?? Outside of debug mode, I don't believe pm-utils writes anything.

One thing I know: I use syslog when I commit my server to sleep (with a direct call to s2ram, not using the pm-utils scripts.) Upon sleep, the very last steps of the trace are not actually written to the log. They are, with the correct date and all, upon wake-up. I suspect the kernel locks IOs when sleeping the devices, or the processing delay within syslog itself is too high.
(When I use syslog to shutdown or reboot, then the trace is complete. Shutting down takes a while and data is synched to disk.)

So I suggest writing an info message before launching sleep if this is needed. I guess this is already done when srvPowerControl is set for some logging level. (Personally I'd choose INFO)
I believe the "logger" command provides a standard (here I've got it on debian linux & macs) and easy way to write to syslog, if you want to add trace to a wrapper script.

[gharris999]

Quickly testing...

sudo /usr/bin/logger SrvrPowerCtrl Suspending_System ; /usr/sbin/pm-suspend --quirk-s3-bios

..while this works from a command line, it doesn't seem to work from SrvrPowerCtrl's system call from perl.

I'll have to clean up SrvrPowerCtrl's code for the next beta release and make sure that only the bare minimum of messages use $log->info() and then I'll change the default.