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
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
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 may have # failed (I tested this: if pm-suspend returns #
Bug#497570: requested output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 $ bash -x /usr/share/acpi-support/suspendorhibernate suspend + . /etc/default/acpi-support ++ SUSPEND_METHODS='dbus-pm dbus-hal pm-utils' ++ ACPI_SLEEP=true ++ ACPI_HIBERNATE=true ++ ACPI_SLEEP_MODE=mem ++ MODULES= ++ MODULES_WHITELIST= ++ VBESTATE=/var/lib/acpi-support/vbestate ++ POST_VIDEO=true ++ USE_DPMS=true ++ HIBERNATE_MODE=shutdown ++ LOCK_SCREEN=true ++ STOP_SERVICES= ++ RESTART_IRDA=false ++ SKIP_INTERFACES='dummy qemu' + . /usr/share/acpi-support/power-funcs ++ umask 022 ++ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 ++ POWERSTATE=/var/lib/acpi-support/powerstate ++ HDPARM='/sbin/hdparm -q' ++ LIDSTATE=/var/lib/acpi-support/lidstate + . /usr/share/acpi-support/device-funcs + . /usr/share/acpi-support/policy-funcs ++ . /usr/share/acpi-support/power-funcs +++ umask 022 +++ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/bin/X11 +++ POWERSTATE=/var/lib/acpi-support/powerstate +++ HDPARM='/sbin/hdparm -q' +++ LIDSTATE=/var/lib/acpi-support/lidstate + . /usr/share/acpi-support/key-constants ++ KEY_RESERVED=0 ++ KEY_ESC=1 ++ KEY_1=2 ++ KEY_2=3 ++ KEY_3=4 ++ KEY_4=5 ++ KEY_5=6 ++ KEY_6=7 ++ KEY_7=8 ++ KEY_8=9 ++ KEY_9=10 ++ KEY_0=11 ++ KEY_MINUS=12 ++ KEY_EQUAL=13 ++ KEY_BACKSPACE=14 ++ KEY_TAB=15 ++ KEY_Q=16 ++ KEY_W=17 ++ KEY_E=18 ++ KEY_R=19 ++ KEY_T=20 ++ KEY_Y=21 ++ KEY_U=22 ++ KEY_I=23 ++ KEY_O=24 ++ KEY_P=25 ++ KEY_LEFTBRACE=26 ++ KEY_RIGHTBRACE=27 ++ KEY_ENTER=28 ++ KEY_LEFTCTRL=29 ++ KEY_A=30 ++ KEY_S=31 ++ KEY_D=32 ++ KEY_F=33 ++ KEY_G=34 ++ KEY_H=35 ++ KEY_J=36 ++ KEY_K=37 ++ KEY_L=38 ++ KEY_SEMICOLON=39 ++ KEY_APOSTROPHE=40 ++ KEY_GRAVE=41 ++ KEY_LEFTSHIFT=42 ++ KEY_BACKSLASH=43 ++ KEY_Z=44 ++ KEY_X=45 ++ KEY_C=46 ++ KEY_V=47 ++ KEY_B=48 ++ KEY_N=49 ++ KEY_M=50 ++ KEY_COMMA=51 ++ KEY_DOT=52 ++ KEY_SLASH=53 ++ KEY_RIGHTSHIFT=54 ++ KEY_KPASTERISK=55 ++ KEY_LEFTALT=56 ++ KEY_SPACE=57 ++ KEY_CAPSLOCK=58 ++ KEY_F1=59 ++ KEY_F2=60 ++ KEY_F3=61 ++ KEY_F4=62 ++ KEY_F5=63 ++ KEY_F6=64 ++ KEY_F7=65 ++ KEY_F8=66 ++ KEY_F9=67 ++ KEY_F10=68 ++ KEY_NUMLOCK=69 ++ KEY_SCROLLLOCK=70 ++ KEY_KP7=71 ++ KEY_KP8=72 ++ KEY_KP9=73 ++ KEY_KPMINUS=74 ++ KEY_KP4=75 ++ KEY_KP5=76 ++ KEY_KP6=77 ++ KEY_KPPLUS=78 ++ KEY_KP1=79 ++ KEY_KP2=80 ++ KEY_KP3=81 ++ KEY_KP0=82 ++ KEY_KPDOT=83 ++ KEY_103RD=84 ++ KEY_ZENKAKUHANKAKU=85 ++ KEY_102ND=86 ++ KEY_F11=87 ++ KEY_F12=88 ++ KEY_RO=89 ++ KEY_KATAKANA=90 ++ KEY_HIRAGANA=91 ++ KEY_HENKAN=92 ++ KEY_KATAKANAHIRAGANA=93 ++ KEY_MUHENKAN=94 ++ KEY_KPJPCOMMA=95 ++ KEY_KPENTER=96 ++ KEY_RIGHTCTRL=97 ++ KEY_KPSLASH=98 ++ KEY_SYSRQ=99 ++ KEY_RIGHTALT=100 ++ KEY_LINEFEED=101 ++ KEY_HOME=102 ++ KEY_UP=103 ++ KEY_PAGEUP=104 ++ KEY_LEFT=105 ++ KEY_RIGHT=106 ++ KEY_END=107 ++ KEY_DOWN=108 ++ KEY_PAGEDOWN=109 ++ KEY_INSERT=110 ++ KEY_DELETE=111 ++ KEY_MACRO=112 ++ KEY_MUTE=113 ++ KEY_VOLUMEDOWN=114 ++ KEY_VOLUMEUP=115 ++ KEY_POWER=116 ++ KEY_KPEQUAL=117 ++ KEY_KPPLUSMINUS=118 ++ KEY_PAUSE=119 ++ KEY_KPCOMMA=121 ++ KEY_HANGUEL=122 ++ KEY_HANJA=123 ++ KEY_YEN=124 ++ KEY_LEFTMETA=125 ++ KEY_RIGHTMETA=126 ++ KEY_COMPOSE=127 ++ KEY_STOP=128 ++ KEY_AGAIN=129 ++ KEY_PROPS=130 ++ KEY_UNDO=131 ++ KEY_FRONT=132 ++ KEY_COPY=133 ++ KEY_OPEN=134 ++ KEY_PASTE=135 ++ KEY_FIND=136 ++ KEY_CUT=137 ++ KEY_HELP=138 ++ KEY_MENU=139 ++ KEY_CALC=140 ++ KEY_SETUP=141 ++ KEY_SLEEP=142 ++ KEY_WAKEUP=143 ++ KEY_FILE=144 ++ KEY_SENDFILE=145 ++ KEY_DELETEFILE=146 ++ KEY_XFER=147 ++ KEY_PROG1=148 ++ KEY_PROG2=149 ++ KEY_WWW=150 ++ KEY_MSDOS=151 ++ KEY_COFFEE=152 ++ KEY_DIRECTION=153 ++ KEY_CYCLEWINDOWS=154 ++ KEY_MAIL=155 ++ KEY_BOOKMARKS=156 ++ KEY_COMPUTER=157 ++ KEY_BACK=158 ++ KEY_FORWARD=159 ++ KEY_CLOSECD=160 ++ KEY_EJECTCD=161 ++ KEY_EJECTCLOSECD=162 ++ KEY_NEXTSONG=163 ++ KEY_PLAYPAUSE=164 ++ KEY_PREVIOUSSONG=165 ++ KEY_STOPCD=166 ++ KEY_RECORD=167 ++ KEY_REWIND=168 ++ KEY_PHONE=169 ++ KEY_ISO=170 ++ KEY_CONFIG=171 ++ KEY_HOMEPAGE=172 ++ KEY_REFRESH=173 ++ KEY_EXIT=174 ++ KEY_MOVE=175 ++ KEY_EDIT=176 ++ KEY_SCROLLUP=177 ++ KEY_SCROLLDOWN=178 ++ KEY_KPLEFTPAREN=179 ++ KEY_KPRIGHTPAREN=180 ++ KEY_F13=183 ++ KEY_F14=184 ++ KEY_F15=185 ++ KEY_F16=186 ++ KEY_F17=187 ++ KEY_F18=188 ++ KEY_F19=189 ++ KEY_F20=190 ++ KEY_F21=191 ++ KEY_F22=192 ++ KEY_F23=193 ++ KEY_F24=194 ++ KEY_PLAYCD=200 ++ KEY_PAUSECD=201 ++ KEY_PROG3=202 ++ KEY_PROG4=203 ++ KEY_SUSPEND=205 ++ KEY_CLOSE=206 ++ KEY_PLAY=207 ++ KEY_FASTFORWARD=208 ++ KEY_BASSBOOST=209 ++ KEY_PRINT=210 ++ KEY_HP=211 ++ KEY_CAMERA=212 ++ KEY_SOUND=213 ++ KEY_QUESTION=214 ++ KEY_EMAIL=215 ++ KEY_CHAT=216 ++ KEY_SEARCH=217 ++ KEY_CONNECT=218 ++ KEY_FINANCE=219 ++ KEY_SPORT=220 ++ KEY_SHOP=221 ++ KEY_ALTERASE=222 ++ KEY_CANCEL=223 ++ KEY_BRIGHTNESSDOWN=224 ++ KEY_BRIGHTNESSUP=225 ++ KEY_MEDIA=226 ++ KEY_VIDEOOUT=227 ++ KEY_UNKNOWN=240 ++ KEY_LOCK=152 ++ KEY_LIGHT=189 ++ KEY_ROTATESCREEN=191 ++ KEY_VIDEOMODECYCLE=192 ++ KEY_PRESENTATION=193 ++ KEY_BATTERY=236 + DeviceConfig ++ cat /var/lib/acpi-support/system-manufacturer + manufacturer='Samsung Electronics'
Bug#497570: requested output
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
