Bug#497570: requested output
Hi again Christian, Could you confirm that if you replace /usr/share/acpi-support/suspendorhibernate by the attached file, that it works? Cheers, Bart Bart Samwel wrote: > Hi Christian, > > Christian Gogolin wrote: >> the output of >> >> $ /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement >> --type=method_call --print-reply --reply-timeout=2000 >> /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend >> >> when run as root is: >> >> Failed to open connection to session message bus: Did not receive a >> reply. Possible causes include: the remote application did not send a >> reply, the message bus security policy blocked the reply, the reply >> timeout expired, or the network connection was broken. >> >> So I think I have a "similar but slightly different problem". >> >> I don't know if that matters, but I am using xmonad as window manager, >> just like Nikolay A. Panov who reported #496911. My xorg version is >> 1:7.3+15. > > I guess the general problem is that I filter out the wrong kind of the > error messages. I was hoping to be able to distinguish between local and > remote errors other than "I don't know how to suspend", and I was doing > that by trying to filter for DBus related errors. Here's what I know: > > - All errors return an error code. > - DBus connection errors do not start with "Error org.freedesktop". > - DBus interface mismatch errors do start with "Error org.freedesktop", > and return defined errors. > - When I forcibly uninstall pm-utils I get: > > Error org.freedesktop.DBus.GLib.UnmappedError.GpmControlError.Code0: > General failure: No suspend method found > > - When I replace /usr/sbin/pm-suspend by a script that does "exit 1", I > get *no error message*, just like when it does "exit 0", and I get a > return code of 0. > > In effect, I think I should just take the return code of dbus-send > instead of trying to filter error messages. If the message was received > by pm-utils on the other end, even if it failed, I should look no > further, and consider it a "succeeded suspend attempt". I'll put this in. > > Cheers, > Bart > > > > #!/bin/sh # # How we handle suspend/hibernate is a bit complicated: # # If gnome-power-manager or klaptopdaemon are running, we send a fake key # and that's it. The daemons may have policies that turn off suspend in # response to suspend keys etc., so we don't want to do anything ourselves. # # If not, we follow the SUSPEND_METHODS setting. # # # This script takes parameter "suspend" or "hibernate". # . /etc/default/acpi-support . /usr/share/acpi-support/power-funcs . /usr/share/acpi-support/device-funcs . /usr/share/acpi-support/policy-funcs . /usr/share/acpi-support/key-constants DeviceConfig; # The difference between suspend and hibernate if [ "$1" = "suspend" ] ; then KEY=$KEY_SLEEP HIBERNATE_CMD=/usr/sbin/hibernate-ram PM_UTILS_CMD=/usr/sbin/pm-suspend DBUS_METHOD=Suspend DBUS_PARAMS="int32:0" elif [ "$1" = "hibernate" ] ; then KEY=$KEY_SUSPEND HIBERNATE_CMD=/usr/sbin/hibernate-disk PM_UTILS_CMD=/usr/sbin/pm-hibernate DBUS_METHOD=Hibernate DBUS_PARAMS= else echo "'Usage: '$0' (suspend|hibernate)'" fi # # Backward compatibility # # Backward compatibility for setting USE_HIBERNATE_PACKAGE if [ "$SUSPEND_METHODS" = "" ] && [ "$USE_HIBERNATE_PACKAGE" = "true" ] && [ -x "$HIBERNATE_CMD" ] ; then SUSPEND_METHODS="hibernate" fi # Backward compatibility for setups before SUSPEND_METHODS existed. if [ "$SUSPEND_METHODS" = "" ] ; then # Legacy configuration -- use the built-in legacy suspend support. We # can NEVER change this explicitly, because it will break people's # working suspend setups, especially ones that depend on custom scripts # in /etc/acpi/suspend.d and /etc/acpi/resume.d. SUSPEND_METHODS="acpi-support" fi # # Try the SUSPEND_METHODS in order. # for METHOD in $SUSPEND_METHODS; do case $METHOD in none) exit ;; dbus-pm) if [ -x /usr/bin/dbus-send ] ; then # Call the power management daemon (which, if it is # running, we probably don't know about, since we send # keys if we detect one running that we know of). if /usr/bin/dbus-send --session \ --dest=org.freedesktop.PowerManagement \ --type=method_call \ --print-reply \ --reply-timeout=2000 \ /org/freedesktop/PowerManagement \ org.freedesktop.PowerManagement.$DBUS_METHOD ; then # The other side exists, we have access to it, # and it received the message. It ma
Bug#497570: requested output
Hi Christian, Christian Gogolin wrote: > the output of > > $ /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement > --type=method_call --print-reply --reply-timeout=2000 > /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend > > when run as root is: > > Failed to open connection to session message bus: Did not receive a > reply. Possible causes include: the remote application did not send a > reply, the message bus security policy blocked the reply, the reply > timeout expired, or the network connection was broken. > > So I think I have a "similar but slightly different problem". > > I don't know if that matters, but I am using xmonad as window manager, > just like Nikolay A. Panov who reported #496911. My xorg version is > 1:7.3+15. I guess the general problem is that I filter out the wrong kind of the error messages. I was hoping to be able to distinguish between local and remote errors other than "I don't know how to suspend", and I was doing that by trying to filter for DBus related errors. Here's what I know: - All errors return an error code. - DBus connection errors do not start with "Error org.freedesktop". - DBus interface mismatch errors do start with "Error org.freedesktop", and return defined errors. - When I forcibly uninstall pm-utils I get: Error org.freedesktop.DBus.GLib.UnmappedError.GpmControlError.Code0: General failure: No suspend method found - When I replace /usr/sbin/pm-suspend by a script that does "exit 1", I get *no error message*, just like when it does "exit 0", and I get a return code of 0. In effect, I think I should just take the return code of dbus-send instead of trying to filter error messages. If the message was received by pm-utils on the other end, even if it failed, I should look no further, and consider it a "succeeded suspend attempt". I'll put this in. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497570: requested output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, the output of $ /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement - --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend when run as root is: Failed to open connection to session message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. So I think I have a "similar but slightly different problem". I don't know if that matters, but I am using xmonad as window manager, just like Nikolay A. Panov who reported #496911. My xorg version is 1:7.3+15. Regards, Christian Gogolin Bart Samwel wrote: > Hi Christian, > > Christian Gogolin wrote: >> $ bash -x /usr/share/acpi-support/suspendorhibernate suspend > [...] >> + for METHOD in '$SUSPEND_METHODS' >> + case $METHOD in >> + '[' -x /usr/bin/dbus-send ']' >> + /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement >> --type=method_call --print-reply --reply-timeout=2000 >> /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend >> + grep -q ' org.freedesktop.DBus.Error.' >> + exit > > It's starting to look more and more like the other problem. Could you > now try running this command (on a single line): > > /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement > --type=method_call --print-reply --reply-timeout=2000 > /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend > > and send us the output? If it's this one: > > ---snip--- > Failed to open connection to session message bus: dbus-launch failed > to autolaunch D-Bus session: Autolaunch error: X11 initialization > failed. > ---snip--- > > then it's the same problem as #496911. If not, then we have a similar > but slightly different problem. > > Cheers, > Bart > - -- address: Christian Gogolin Schillerstr. 2 97209 Veitshöchheim contact: e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] phone: +49 179 - 8 39 49 79 +49 931 - 40 40 98 68 website: http://www.cgogolin.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjAClUACgkQOYJY/BTv8jHhOACgsrHZsREUnpi7QLEtIH/NhBJA QqAAoLJzDE0v6a3bwxjg1vNe8hqWqoNd =Gkap -END PGP SIGNATURE- begin:vcard fn:Christian Gogolin n:Gogolin;Christian email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard
