Ubuntu

kde power button configuration ignored

Reported by Tom Chiverton on 2010-04-01
80
This bug affects 12 people
Affects Status Importance Assigned to Milestone
KDE Base
Unknown
Medium
acpid (Ubuntu)
Undecided
Unassigned
Declined for Lucid by Jonathan Thomas

Bug Description

Even though in 'power management' I have 'when power button pressed' set to 'suspend to disk' set in all profiles (and can confirm which is selected via the system tray icon), nothing happens when I press the power button.

This worked in KDE 4.x under 9.10, appears broken by using the 10.4 beta.

Hardware is a Dell Inspiron 1525 laptop.

Philip Muškovac (yofel) wrote :

I think powerdevil should be responsible for that.

tags: added: lucid
affects: ubuntu → kdebase-workspace (Ubuntu)
Changed in kdebase:
status: Unknown → New

Worse under Ubuntu 10.4 beta 2's packages, now the screen changes to a Kubuntu
logo with animated dots underneath and hangs there.

CTRL-ALT-F1 swaps to text console but the keyboard doesn't respond when I try
to login.

I *suspect* it's trying to reboot, and the hang is due to my CIFS mounts not
being pulled down before the wireless is, but that's a different bug; it should
be hibernating, not rebooting.

Using the 'suspend to disk' option on the logout dialogue all is well.

This was rock solid under 9.10 with Kubuntu backports of the same KDE4
version...

Jon Packard (jonpackard) wrote :

I am experiencing similar behavior using Kubuntu Lucid Beta 2. Even though power button is set to give the logout dialog in all power profiles, instead the system is powered off.

summary: - kde power button
+ kde power button configuration ignored

Using buttons added to the main menu panel work fine too.

Still broken in 10.4 release :-( Only now it's worse because when the Kubuntu logo comes up, the machine is now hard-locked (num lock, caps lock do not light the LEDs and ctrl-alt-del or ctrl-alt-F1 ignored) and I have to hold down the power button to power down.
Settings are still set to hibernate in all profiles on button press.

Jon, what's your hardware ?

@Tom
I was running Kubuntu on a Dell Latitude D630 (Core2Duo with Intel
graphics), but have gone back to Ubuntu shortly after commenting on this
bug. No problems on Ubuntu 10.04.

On Fri, Apr 30, 2010 at 1:48 PM, Tom Chiverton <bugs.launchpad.net@
falkensweb.com> wrote:

> Using buttons added to the main menu panel work fine too.
>
> Still broken in 10.4 release :-( Only now it's worse because when the
> Kubuntu logo comes up, the machine is now hard-locked (num lock, caps lock
> do not light the LEDs and ctrl-alt-del or ctrl-alt-F1 ignored) and I have to
> hold down the power button to power down.
> Settings are still set to hibernate in all profiles on button press.
>
> Jon, what's your hardware ?
>
> --
> kde power button configuration ignored
> https://bugs.launchpad.net/bugs/553557
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in KDE Base Components: New
> Status in “kdebase-workspace” package in Ubuntu: New
>
> Bug description:
> Even though in 'power management' I have 'when power button pressed' set to
> 'suspend to disk' set in all profiles (and can confirm which is selected via
> the system tray icon), nothing happens when I press the power button.
>
> This worked in KDE 4.x under 9.10, appears broken by using the 10.4 beta.
>
> Hardware is a Dell Inspiron 1525 laptop.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/kdebase/+bug/553557/+subscribe
>

Adam Porter (alphapapa) wrote :

I doubt that this is a bug in KDE itself, especially since it worked in the Lucid betas. It would probably be good to close the bug on the KDE tracker so it doesn't waste the KDE folks' time. This is almost surely a bug in Kubuntu.

Adam: It didn't work for me in the Lucid betas.
It worked for me last using Kubuntu's KDE4.4 backports PPA on their 9.10 release.
Running the stock Kubuntu 10.4 (since first beta) it has never worked.

However, Jon's comment in #6 seems to concur with you...

Philip Muškovac (yofel) wrote :

Ok, it works fine here, but this sounds familiar. Just to make sure this isn't related to acpi, please edit /etc/acpi/powerbtn.sh (which handles the acpi power button key press event) and replace the last line

/sbin/shutdown -h now "Power button pressed"

with something like

#/sbin/shutdown -h now "Power button pressed"
touch /tmp/powerbutton.fail

and check if it works then and if you have a "powerbutton.fail" file in /tmp.

Confirmed, you are spot on, something is causing that script to fail to spot KDE is running, and it *was* falling though to the end.

I'll poke at it and see if I can locate what goes wrong... initial testing by putting the code from the main script into the command line (konsole) indicates it's in the support functions.

falken@wopr:~$ . /usr/share/acpi-support/power-funcs
falken@wopr:~$ getXuser() {
> user=`pinky -fw | awk '{ if ($2 == ":'$displaynum'" || $(NF) == ":'$displaynum'" ) { print $1; exit; } }'`
> if [ x"$user" = x"" ]; then
> startx=`pgrep -n startx`
> if [ x"$startx" != x"" ]; then
> user=`ps -o user --no-headers $startx`
> fi
> fi
> if [ x"$user" != x"" ]; then
> userhome=`getent passwd $user | cut -d: -f6`
> export XAUTHORITY=$userhome/.Xauthority
> else
> export XAUTHORITY=""
> fi
> export XUSER=$user
> }
falken@wopr:~$ getXconsole
Couldn't get a file descriptor referring to the console
falken@wopr:~$ echo $XUSER

falken@wopr:~$

Download full text (9.9 KiB)

That single line of output comes from the first line of the getXconsole method in /usr/share/acpi-support/power-funcs

falken@wopr:~$ fgconsole
Couldn't get a file descriptor referring to the console
falken@wopr:~$

The strace shows some permission denied errors for opening devices in /dev/ but I dunno if that's normal or not. I think that that means getXuser (which is overridden in the main powerbutn.sh) is never called, and so XUSER is never set. This means the script falls down to the bottom.
Bah.

falken@wopr:~$ strace fgconsole
execve("/bin/fgconsole", ["fgconsole"], [/* 42 vars */]) = 0
brk(0) = 0x8693000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77bd000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=126614, ...}) = 0
mmap2(NULL, 126614, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb779e000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000m\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1405508, ...}) = 0
mmap2(NULL, 1415592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b5000
mprotect(0x408000, 4096, PROT_NONE) = 0
mmap2(0x409000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x153) = 0x409000
mmap2(0x40c000, 10664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40c000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb779d000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb779d8d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x409000, 8192, PROT_READ) = 0
mprotect(0x804a000, 4096, PROT_READ) = 0
mprotect(0xe1a000, 4096, PROT_READ) = 0
munmap(0xb779e000, 126614) = 0
brk(0) = 0x8693000
brk(0x86b4000) = 0x86b4000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77bc000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb77bc000, 4096) = 0
open("/usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=373, ...}) = 0
mmap2(NULL, 373, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77bc000
close(3) = 0
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3
fstat64(3...

Download full text (3.2 KiB)

Scratch #11, wasn't running as root, which of course the powerbtn.sh would be :-)

Cut'n'paste tests now show
... as before ...
root@wopr:~# getXconsole
root@wopr:~# echo $XUSER
falken
root@wopr:~# test "$XUSER" != "" && pidof dcopserver > /dev/null && test -x /usr/bin/dcop && /usr/bin/dcop --user $XUSER kded kded loadedModules | grep -q klaptopdaemon
root@wopr:~# echo $?
1
root@wopr:~# test "$XUSER" != "" && test -x /usr/bin/qdbus && test -r /proc/$(pidof kded4)/environ && su - $XUSER -c "eval $(echo -n 'export '; cat /proc/$(pidof kded4)/environ |tr '\0' '\n'|grep DBUS_SESSION_BUS_ADDRESS); qdbus org.kde.kded" | grep -q powerdevil
-bash: test: too many arguments

Ahh ha ! That is the line that's meant to spot KDE4 and poke it... it looks like a horrible undocument mess to me though.

root@wopr:~# pidof kded4
14371 2153 1955
root@wopr:~# ps -efww|grep kded4
falken 1955 1 0 May01 ? 00:01:23 kdeinit4: kded4 [kdeinit]
falken 2153 1955 0 May01 ? 00:00:00 [kded4] <defunct>
root 14371 1 0 May03 ? 00:00:02 kdeinit4: kded4 [kdeinit]
root 20826 20690 0 22:43 pts/1 00:00:00 grep kded4

I found the process I think it should be asking for, and it looks like it should work:
root@wopr:~# cat /proc/1955/environ |tr '\0' '\n'|grep DB
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-wZqbwHsRWt,guid=a017520a52ed70c025d498814bdc07f1
root@wopr:~# su - $XUSER -c "eval export DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-wZqbwHsRWt,guid=a017520a52ed70c025d498814bdc07f1; qdbus org.kde.kded"|grep powerdevil
/modules/powerdevil
root@wopr:~#

As a suggestion, the final test should replace 'pidof kded4' with 'ps -efww|grep kded4|grep $XUSER|grep -v grep|grep -v defunct
' or similar.
I do not believe the defunct is the problem, rather there are many kded4's (one for me, one for root, one for every user logged in ?). I've filtered out defunct ones anyway, and also restricted it to the current X user name. This should more reliably locate the one KDE instance we are interested in.

This appears to work:
PIDOFKDE4=`ps -efww|grep kded4|grep $XUSER|grep -v grep|grep -v defunct|tr -s ' '|awk '{print $2}'`

if pidof x $PMS > /dev/null ||
         ( test "$XUSER" != "" && pidof dcopserver > /dev/null && test -x /usr/bin/dcop && /usr/bin/dcop --user $XUSER kded kded loadedModules | grep -q klaptopdaemon) ||
         ( test "$XUSER" != "" && test -x /usr/bin/qdbus && test -r /proc/$PIDOFKDE4/environ && su - $XUSER -c "eval $(echo -n 'export '; cat /proc/$PIDOFKDE4/environ |tr '\0' '\n'|grep DBUS_SESSION_BUS_ADDRESS); qdbus org.kde.kded" | grep -q powerdevil) ; then
 echo hello
fi

Attached is a a version of powerbtn.sh that works for me.
Someone with more Bash voodoo might want to take a look at this.

Using this version, with a power button press, hibernate and resume betwen the two ls's :
root@wopr:~# ls -lah /tmp/powerbutton.fail
-rw-r--r-- 1 root root 0 2010-05-03 22:01 /tmp/powerbutton.fail
root@wopr:~# date
Tue May 4 23:10:10 BST 2010
root@wopr:~# ls -lah /tmp/powerbutton.fail
-rw-r--r-- 1 root root 0 2010-05-03 22:01 /tmp/powerbutton.fail
root@wopr:~# date
Tue May 4 23:12:20 BST 2010

this...

Read more...

affects: kdebase-workspace (Ubuntu) → acpid (Ubuntu)

There was an acpid update today, here are my suggested changes merged into the new version.

Tom Helner (duffman) wrote :

Since my upgrade to 10.04 I am seeing the exact behavior as Tom describes above.

This line in /etc/acpi/powerbtn.sh fails for me because "pidof kded4" is returning 2 PIDs (one is defunct, also new since upgrade):

        ( test "$XUSER" != "" && test -x /usr/bin/qdbus && test -r /proc/$(pidof kded4)/environ && su - $XUSER -c "eval $(echo -n 'export '; cat /proc/$(pidof kded4)/environ |tr '\0' '\n'|grep DBUS_SESSION_BUS_ADDRESS); qdbus org.kde.kded" | grep -q powerdevil) ; then

Which causes "/sbin/shutdown -h now "Power button pressed"" to be run.

As Tom describes, changing powerbtn.sh to use the following works for me:
PIDOFKDE4=`ps -efww|grep kded4|grep $XUSER|grep -v grep|grep -v defunct|tr -s ' '|awk '{print $2}'`

https://bugs.launchpad.net/ubuntu/+source/kde4libs/+bug/515138 sees almost the same issue with defunct process' that triggers this bug, asks to report upstream, but I can't locate one.
However, I think that's a different issue as I've now hibernated twice, and still have just the one defunct process.
There's nothing in the KDE issue tracker, so I've opened https://bugs.kde.org/show_bug.cgi?id=236490

I think these ACPI scripts need to be more robust weather it's a common issue or not however.

Changed in kdebase:
status: New → Invalid
Philip Muškovac (yofel) wrote :

Switched tracked upstream report.

Changed in kdebase:
status: Invalid → Unknown
Changed in kdebase:
status: Unknown → New
Manuel Bärenz (turion) wrote :

I am experiencing a kind of the same bug: I have two kded4's and one of them defunct.
When I press the power button, the computer immediately shuts down.
But playing on the /etc/acpi/powerbtn.sh doesn't change behaviour at all! I commented out the /sbin/shutdown line and it still went down. I even renamed it do powerbtn.sh.disable and it still goes down. So is there some additional bug in kde? Or did I miss a step that Tom did?

I assume you've double checked the KDE power settings, but other than that I can't think of anything else unless it's a separate issue.

Manuel Bärenz (turion) wrote :

I checked it a few more times with different settings and found out, that it actually kind of works:
When I disable the powerbtn.sh, the system still shuts down without asking, but it seems to log out from the kde session at least. This holds for the kde setting "Shut down on power button pressed".
If I change the kde setting to e.g. "logout", it correctly shows the logout screen.

If I now enable the script handicapped, to say with the shutdown command replaced by "touch sometestfile", the file sometestfile is produced every time I press the power button, of course regardless of the kde setting. This is the expected buggy behaviour.
I have, by the way, lucid running on an Compaq nx6325 with an AMD64 processor.

So in conclusion, my situation: The bug is there, it's in the script powerbtn.sh, as described by previous. However, kde in some way watches separately if the power button pressed and interprets it correctly according to the settings.
So why is the script still kept? My workaround is disabling it.

Juliano Ravasi (jravasi) on 2010-08-05
description: updated
Changed in kdebase:
status: New → Confirmed

A new version of /etc/acpi/powerbtn.sh arrived today in updates, oddly(?) with no comment here.

From my testing of pressing the power button, the action I have set in KDE is now honoured.

From testing the new script directly, it returns a 0 in the place I expect, and calling the methods as intended also works OK.
root@wopr:~# . /usr/share/acpi-support/policy-funcs
root@wopr:~# `CheckPolicy`
0: command not found
root@wopr:~# if ( [ `CheckPolicy` = 0 ] || CheckUPowerPolicy ); then echo "exiting"; fi
exiting
root@wopr:~#

Workaround (at least of 10.10) is to simply uninstall the acpid and acip-support packages (including configuration files i.e. 'purge').
No ill effects observed yet, but I've not really checked battery life or anything.

Sorry, this is still busted.
If you remove (and purge) acpid and acpi-support and reinstall them (on 10.10), it still breaks.
I commented the last line of /etc/acpi/powerbtn.sh out and then added a 'touch' line to show the detection of KDE fails.

falken@wopr:/tmp$ ls -lah
total 48K
drwxrwxrwt 9 root root 12K 2010-11-10 21:47 .
drwxr-xr-x 26 root root 4.0K 2010-11-05 21:27 ..
drwx------ 2 falken falken 4.0K 2010-11-10 21:47 .esd-1000
drwxrwxrwt 2 root root 4.0K 2010-11-10 21:47 .ICE-unix
drwx------ 2 falken falken 4.0K 2010-11-10 21:47 kde-falken
drwx------ 2 falken falken 4.0K 2010-11-10 21:47 ksocket-falken
drwx------ 2 falken falken 4.0K 2010-11-10 21:47 pulse-s6YhteYQrpJA
drwx------ 2 falken falken 4.0K 2010-11-10 21:47 ssh-rVZOMZ1835
-r--r--r-- 1 root root 11 2010-11-10 21:46 .X0-lock
drwxrwxrwt 2 root root 4.0K 2010-11-10 21:46 .X11-unix

...press power button, hibernates, press power button and machine resumes...

falken@wopr:/tmp$ ls -lah
.
.
.
-rw-r--r-- 1 root root 0 2010-11-10 21:49 fail
.
.
.

Simple testing confirms the X session detected appears to be busted *again*.
root@wopr:~# [ -r /usr/share/acpi-support/power-funcs ] && . /usr/share/acpi-support/power-funcs
root@wopr:~# getXuser() {
> user=`pinky -fw | awk '{ if ($2 == ":'$displaynum'" || $(NF) == ":'$displaynum'" ) { print $1; exit; } }'`
> if [ x"$user" = x"" ]; then
> startx=`pgrep -n startx`
> if [ x"$startx" != x"" ]; then
> user=`ps -o user --no-headers $startx`
> fi
> fi
> if [ x"$user" != x"" ]; then
> userhome=`getent passwd $user | cut -d: -f6`
> export XAUTHORITY=$userhome/.Xauthority
> else
> export XAUTHORITY=""
> fi
> export XUSER=$user
> }
root@wopr:~#
root@wopr:~# [ -r /usr/share/acpi-support/power-funcs ] && getXconsole
root@wopr:~# PMS="gnome-power-manager kpowersave xfce4-power-manager"
root@wopr:~# PMS="$PMS guidance-power-manager.py dalston-power-applet"
#now the main if statement from powerbtn.sh, modified to echo what is going on:
root@wopr:~# if pidof x $PMS > /dev/null || ( test "$XUSER" != "" && pidof dcopserver > /dev/null && test -x /usr/bin/dcop && /usr/bin/dcop --user $XUSER kded kded loadedModules | grep -q klaptopdaemon) || ( test "$XUSER" != "" && test -x /usr/bin/qdbus && test -r /proc/$(pidof kded4)/environ && su - $XUSER -c "eval $(echo -n 'export '; cat /proc/$(pidof kded4)/environ |tr '\0' '\n'|grep DBUS_SESSION_BUS_ADDRESS); qdbus org.kde.kded" | grep -q powerdevil) ; then echo "win"; fi ; echo "fail"
fail
root@wopr:~#

Oh, look, and it's because of the exact same bug the last update fixed:
root@wopr:~# pidof kded4
2383 2008
root@wopr:~#

Where's the 'regression' option :-)

Adam Porter (alphapapa) wrote :

:( Well, at least we'll have Unity and Wayland soon. Those will
distract us from these bugs, right? Right? ...

On Wed, Nov 10, 2010 at 16:03, Tom Chiverton <email address hidden> wrote:
> Oh, look, and it's because of the exact same bug the last update fixed:
> root@wopr:~# pidof kded4
> 2383 2008
> root@wopr:~#
>
> Where's the 'regression' option :-)
>
> --
> kde power button configuration ignored
> https://bugs.launchpad.net/bugs/553557
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Adam Porter (alphapapa) wrote :

So...two releases later...still not fixed.

Changed in acpid (Ubuntu):
status: New → Confirmed
Adam Porter (alphapapa) wrote :

By the way, I'd really like to know why fixing this bug was declined for Lucid, an LTS. This is actually a DATA LOSS bug, because if someone presses the power button, even by accident (children? pets?), the system will power off WITHOUT SAVING DATA. This is unacceptable, and yet another example of extremely poor handling of bugs by Ubuntu.

tags: added: maverick
tags: added: dataloss
michael (reeves-87) wrote :

This patch should resolve the issue. I modified powerbtn.sh to account for multiple kded4 instances running and added a little documentation explaining this since it seems to be a repeat problem.

tags: added: patch
Changed in kdebase:
importance: Unknown → Medium

Still busted in natty, but I can't see the nominate button...

Adam Porter (alphapapa) wrote :

$ pidof kded4
9332 9331 9328 9327 3159 2789
$ pg kded4
 2789 ? Sl 0:15 kdeinit4: kded4 [kdeinit]
 3159 ? Z 0:00 [kded4] <defunct>
 4402 pts/1 D+ 0:00 grep --color=auto -i kded4
 9327 ? Z 0:00 [kded4] <defunct>
 9328 ? Z 0:00 [kded4] <defunct>
 9331 ? Z 0:00 [kded4] <defunct>
 9332 ? Z 0:00 [kded4] <defunct>

What a mess. Yet it would seem so simple to ignore the defunct processes (why do they still exist as zombies??). Please don't tell me that this bug is going to be in yet another Kubuntu release.

Like Tom said: where's the nominate button gone?

Malte S. Stretz (mss) wrote :

There are actually two bugs mangled here. The do-not-ask-before-shutdown bug is in powerbtn.sh and caused by duplicated kded4 processes. The upstream KDE bug is about what actually creates these processes, especially the zombies. It seems like it was tracked to downstream again and the Ubuntu Notification Helper is causing this.

BTW, I see/saw this bug under different circumstances: Back when NM still sucked, I had to use kvpnc to connect to a VPN. That one had to be started as root, causing a second kded process to be spawned (owned by root). That one would break the powerbtn.sh script. I think it still happens sometimes accidently with other apps.

The last few lines in the powerbtn.sh script is a big WTF BTW.

Yeah, to an extent it doesn't matter why the other kded's are there, the script hasn't been programmed defensively, and although it was fixed at some point, those changes have been reverted, making it worse irrespective of it KDE fix their issue or not (it might be fixed in Natty, hard to tell because it was so intermittent for me).

Adam Porter (alphapapa) wrote :

I think this bug needs to be marked as Critical importance for the acpi (Ubuntu) package, because this is a data-loss bug! Instant system shutdown without confirmation or prompting to save data is...data-loss! This *needs* to be fixed before Natty is released.

tags: added: natty

Busted in 11.11 beta 2 still

tags: added: oneiric
Changed in kde-baseapps:
status: Confirmed → Unknown

Why has this changed status ?

Philip Muškovac (yofel) wrote :

The upstream bug was changed to resovled/downstream, launchpad doesn't know what that means so the Bug Watch Updater set it to Unkown. That's automated.
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

michael (reeves-87) wrote :

This bug appears to have been fixed as side effect of a security update that just posted today. The targeted fix was LP#893821.

aboaboit (andrea-borgia) wrote :

With yesterday's updates to Kubuntu 11.10 (64bit), it now works on my EEEpc 1215p. Only (minor) glitch, which might as well depend on the specific hw I have, is that the dialog box pops up after 10 seconds or so. This only happens the first time, though.

Dennis Schridde (devurandom) wrote :

(In reply to comment #37)
> the dialog box pops up after 10 seconds or so. This only happens the first time, though.
Have a look at bug #713198

Adam Porter (alphapapa) wrote :

It's a shame that data-loss wasn't reason enough to get it fixed. It took a much more obscure security bug, one that's very unlikely to occur in the real world. The data-loss angle is an everyday risk: press the power button, expecting to get prompted to shutdown, and watch all your X apps get killed, instead.

Hey, I'm glad they fixed the security aspect, but let's be realistic here: If a user has the ability to run processes on the system, and the system is a laptop or desktop running KDE 4, most likely the user has physical access to the system, and he could snoop-on or erase data without having to jump through such obscure hoops. On the other hand, the data-loss aspect could happen because of a cat or a dog or a two-year-old--or a forgetful adult.

*sigh* Priorities...

This is busted in 12.04 beta again. Pressing the power button just activates the screen saver instead of hibernate.

If I add
echo a > /tmp/a
to the top of /etc/acpi/powerbtn.sh I never get this output created !

michael (reeves-87) wrote :

@Tom LP:812394 is hibernation specific. Does it result in powerdevil or similar not starting?

michael (reeves-87) wrote :

sorry not reading.

Marius B. Kotsbak (mariusko) wrote :

I do not reproduce this in Kubuntu 12.04 with all updates. Changing to lock screen instead of shutdown menu gives that effect when pushing the power button.

Changed in acpid (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.