Announce: Beta version of SvrPowerControl

[gharris999]

This OSX sleep issue must have been bubbling away for a quite some time, I think.

What would you guess the demand would be for this sort of solution on pre Leopard systems? How many Tiger SBS systems are out there, do you suppose?

I did run across some code this afternoon that uses the same api as SleepWatcher...code that I think I could shoe-horn into a Tiger version of my utility. Basically, it would still operate the same, with a timer killing the run loop in order to terminate the program. But it could also register for power management notification, just like SleepWacher does, and the pm callback could deny the any sleep requests that come in before the timer expires.

Admittedly, this is a simplistic approach. I'm just trying to avoid having to write sockets code on OSX. Having a full-blown power state monitoring daemon that communicates with SBS via the cli would take this work full circle. This was the approach advocated by epoch1970 a few years ago. I resisted it then, and I guess I'm still resisting it simply because I know I'll end up spending months trying to get the sockets code right and portable between osx, windows & linux. Also, while I've got a code example for OSX now and I have a good idea about how to accomplish the same thing in C on Windows, I don't have much of a clue about how to write a power monitor daemon under linux. I've found the gnome session-manager documentation to be sketchy, without many examples in C of utilities interacting with the session-manager.

[mrw]

What would you guess the demand would be for this sort of solution on pre Leopard systems? How many Tiger SBS systems are out there, do you suppose?

Leopard was released in October 2007, I think. So there are probably quite a lot of running Tiger systems. Tiger SBS systems ? Pass. I upgraded mine to Leopard about 6 months ago.

Admittedly, this is a simplistic approach. I'm just trying to avoid having to write sockets code on OSX. Having a full-blown power state monitoring daemon that communicates with SBS via the cli would take this work full circle.

My guess is that the "simplistic" approach is actually the best approach, because it hooks the system where needed. Why get involved in sockets etc. when the OS hook is both direct and effective ?

I posted an update to my original task/script. It might satisfy the handful (?) of Tiger users that exist. It satisfied me for 2+ years.
I wonder if more than 3 people will download it ?

Probably good to prove the current sleep-inhibit tool out in the field without clouding it with lots of:

if OSX 10.4 do this, but don't do that or the tool will break
because that symbol is only available on 10.5

Perhaps I'm overstating the problem.

The Tcl/Expect script (either variant) may also be useful on Linux systems, in the sense that an existing power monitor daemon might call it as part of a monitoring process.
But I have no knowledge of how the various Linux distributions organize power management.

The sockets code I put in the script probably wants some refinement, it's just a first draft that I think will become useful to me in other contexts.

[gharris999]

I am okay to continue using 7.5.2, which was already my plan of action, since I do like to use your plugin.

I guess I was hoping that for the users of the latest Vortexbox release, either that SvrPowerControl is working for them, (perhaps indicating that my home-brew hardware is atypical), or that a fix could eventually be provided.

From my own selfish perspective, I do not need any further help, but wanted to report my findings anyway. Thanks for your work on SvrPowerControl.

OK, I finally got around to trying this. I can't even get the latest released version, squeezeboxserver-7.5.2-1.noarch.rpm, to run on my F14 system. But squeezeboxserver-7.5.3-0.1.31678.noarch.rpm installs and runs just fine and SrvrPowerCtrl doesn't seem to have a problem with it. I do see a couple of perl warning messages show up in the log about 'defined(@array)' being deprecated..but that's minor.

Bottom line: I can't test SrvrPowerCtrl on Fedora 14 with the latest released SBS if I can't get SBS itself to run.

[Clnanderson]

Having problems with this under Ubuntu 10.10. Hope this is the right place to post questions about gsession-inhibit.itI'm probably doing something silly.

Here's the basics:

Linux 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 01:41:57 UTC 2010 i686 GNU/Linux

Squeezeboxserver: Version: 7.5.2 - r31632 @ Mon Dec 13 13:06:10 PST 2010

ReallyPreventStandby 20101213.144758

Running on an Zotac ION-itxc mobo. Unbuntu 10.10.

Here's gsession-inhibit.log

20110107-111514 AppID == gsession-inhibit-ca
20110107-111514 AppPath == /var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/ReallyPreventStandby/bin/unix/gsession-inhibit
20110107-111514 AppData == /usr/share/squeezeboxserver/.gsession-inhibit
20110107-111514 AppLog == /var/log/gsession-inhibit.log
20110107-111514 AppReason == not_idle
20110107-111514 AppOpts == 0x0000b001
20110107-111514 InhibitSecs == 60
20110107-111514 InhibitType == 0x0000000f
20110107-111514 Display env == :0
20110107-111514 Error: Inhibit failure. The name org.gnome.SessionManager was not provided by any .service file

I assume that the last line is the sign of the problem. The computer sleeps and wakes properly and wol works from the squeezecenters and I can use servercontrol plugin to put the computer to sleep. Just not inhibit for some reason.

Here's the entry from squeezecenter's log preceding this, which seems to show a successful call from Squeezecenter.

[11-01-07 11:15:14.0021] Plugins::ReallyPreventStandby::Plugin::_playersBus y (521) Player Squeezeboom2 is busy...
[11-01-07 11:15:14.0030] Plugins::ReallyPreventStandby::Plugin::checkClient Activity (451) Resetting idle counter. 20 minutes left in allowed idle period.
[11-01-07 11:15:14.0142] Plugins::ReallyPreventStandby::Plugin::_getGnomeUs er (312) Gnome User == ca Display == :0
[11-01-07 11:15:14.0155] Plugins::ReallyPreventStandby::Plugin::_inhibitGno me (374) Executing command: "sudo -u ca /var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/ReallyPreventStandby/bin/unix/gsession-inhibit -l -d 60 --quiet >/dev/null 2>&1 &"
[11-01-07 11:15:14.0258] Plugins::ReallyPreventStandby::Plugin::_inhibitGno me (380) system call returned 0

I was having trouble with waking up from acpi prior to this and added a few kernel options:

usbcore.autosuspend=-1 acpi_enforce_resources=lax acpi_sleep=nonvs

I'm not entirely sure what these do, though they fixed my waking from suspend problems, but perhaps they're relevant.

[gharris999]

Having problems with this under Ubuntu 10.10. Hope this is the right place to post questions about gsession-inhibit.itI'm probably doing something silly.

Here's the basics:



Here's gsession-inhibit.log



I assume that the last line is the sign of the problem. The computer sleeps and wakes properly and wol works from the squeezecenters and I can use servercontrol plugin to put the computer to sleep. Just not inhibit for some reason.

Here's the entry from squeezecenter's log preceding this, which seems to show a successful call from Squeezecenter.



I was having trouble with waking up from acpi prior to this and added a few kernel options:



I'm not entirely sure what these do, though they fixed my waking from suspend problems, but perhaps they're relevant.

Sorry to take so long to respond to this. I've been in Tucson at a memorial service.

A couple of questions:

I'm not sure I've stated this in the ReallyPreventStandby documentation, but I think gsession-inhibit will only work if there is an active gnome user session..i.e. a user needs to be logged in to a gnome session. In your case, was the user "ca" (as indicated in the log) logged in?

Does gsession-inhibit work for you from a terminal session?

Try this:

Open a gnome terminal window and paste the following into the window:

cat >~/Desktop/check-inhibit.sh <<EOF;
#!/bin/bash

for i in {0..1000..1}
  do
    INHIBIT=\`dbus-send --print-reply --dest=org.gnome.SessionManager /org/gnome/SessionManager org.gnome.SessionManager.IsInhibited uint32:-1\`
    if [[ "\$INHIBIT" =~ "true" ]]
      then
        echo "Inhibited.."
      else
        echo "Not inhibited.."
      fi

    #echo $?
    sleep 1
 done
sleep 30
EOF
chmod 755 ~/Desktop/check-inhibit.sh

That will create a small script file, check-inhibit.sh on your desktop. Double click on check-inhibit.sh and select "Run in terminal..". This should result in a new terminal window opening and the message "Not inhibited.." appearing every second.

Now, in your original terminal window, paste in this command:

# /var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/ReallyPreventStandby/bin/unix/gsession-inhibit -l -d 60

Does the check-inhibit.sh terminal message change to "Inhibited.."?

Thanks..

[Clnanderson]

Thanks for the reply.

There is a gnome session open under username ca.

Yes, it does switch from uninhibited to inhibited.

[gharris999]

Thanks for the reply.

There is a gnome session open under username ca.

Yes, it does switch from uninhibited to inhibited.

Humm...I'm stumped. Please forgive one other obvious question: You do have the "Monitor Idle Players?" option turned OFF in SrvrPowerCtrl, don't you?

ReallyPreventStandby is designed to allow GnomePowerManager to do it's job, sending the system to sleep on it's own schedule. In other words, with ReallyPreventStandby, you should let GnomePowerManager do all the power management stuff and relieve SrvrPowerCtrl of those duties.

If SrvrPowerCtrl is still actively monitoring for idle players and firing off pm-suspend commands, those will trump the inhibition set by gsession-inhibit.

The log entry you flagged, to me, looks like something one would expect to see if you were using a different version of GnomeSessionManager. But I developed gsession-inhibit on a 10.10 system so that seems really unlikely.

Plus, gsession-inhibit is working from a command line. Could this be a user permissions problem? Could you post your /etc/sudoers entry granting squeezeboxserver permissions to gsession-inhibit?

Sorry to flail like this...but my knowledge of Gnome, linux and all the potentially allied issues is cursory at best.

[Clnanderson]

Thanks for your help with this, any suggestions for things to check is helpful for me, and I appreciate your willingness to help me out!

Here's the sudoers entry

squeezeboxserver ALL = (ALL) NOPASSWD: /var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/ReallyPreventStandby/bin/unix/gsession-inhibit*
squeezeboxserver ALL = (ALL) NOPASSWD: /usr/bin/killall -9 gsession-inhibit

"monitor idle players" is unchecked in SrvrPowerCtrl settings

the command line in the plugin settings is

sudo -u %u /var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/ReallyPreventStandby/bin/unix/gsession-inhibit -l -d %t


When I first installed ReallyPreventStandby it worked fine, but then in the course of trying to get wol to work properly I think I installed SrvrPowerCtrl (I'm not entirely sure on the time-line anymore). I'll experiment today by removing the latter and see if that restores it.

[gharris999]

Thanks for your help with this, any suggestions for things to check is helpful for me, and I appreciate your willingness to help me out!

Here's the sudoers entry


"monitor idle players" is unchecked in SrvrPowerCtrl settings

the command line in the plugin settings is

sudo -u %u /var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/ReallyPreventStandby/bin/unix/gsession-inhibit -l -d %t


When I first installed ReallyPreventStandby it worked fine, but then in the course of trying to get wol to work properly I think I installed SrvrPowerCtrl (I'm not entirely sure on the time-line anymore). I'll experiment today by removing the latter and see if that restores it.

Your sudoers entries look OK. On my system, ReallyPreventStandby and SrvrPowerCtrl coexist with no problems.

This is really grasping at straws, but you could look at the output of:

# sudo cat /var/log/apt/term.log | grep "Setting up "

That will give you a history of packages that you've installed. Off hand, I can't think of a reason as to why gsession-inhibit should have a conflict with any package other than a major gnome desktop upgrade, but who knows?

[Tarik]

Help!

I have just installed the SvrPowerControl and SCPowerTool utility.

When I run the shutdown command from a command prompt the system shuts down as expected. When run form the squeezebox or the webpage it does not work. A message is given that the system is shutting down but it never happens.

I am running Windows Vista Pro x64 and version 7.5.2 of squeezebox server.

Any ideas?