Bug#755969: acpi-support: Upgrade to 0.140-5+deb7u1 breaks suspend to RAM: forced shutdown after return

[Michael Fiedler]

Package: acpi-support
Version: 0.140-5+deb7u1
Severity: important

Dear Maintainer,


* What led up to the situation?

My power button is configured (probably using GNOME settings a longer time
ago) to cause suspend to RAM. Pressing it again makes the computer wake
up. That worked well until upgrade to version 0.140-5+deb7u1 of the acpi
packages a few days ago.

With the new package version, the computer is shut down immediately
after wake up from suspend to RAM. The graphical user interface is
killed and on the console I can see "Power butten pressed" and
"The system is going down for halt now".

This can cause loss of data as open applications are killed.


* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?

Downgrading the acpi packages

acpi-support-base acpi-support acpi-fkekey

back to previous version 0.140-5 makes suspend to RAM work as expected
again.



-- System Information:
Debian Release: 7.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages acpi-support depends on:
ii acpi-fakekey 0.140-5
ii acpi-support-base 0.140-5
ii acpid 1:2.0.16-1+deb7u1
ii lsb-base 4.1+Debian8+deb7u1
ii pm-utils 1.4.1-9
ii x11-xserver-utils 7.7~3

Versions of packages acpi-support recommends:
ii dbus 1.6.8-1+deb7u3
ii gnome-screensaver 3.4.1-1
ii radeontool 1.6.2-1.1
ii vbetool 1.1-2

Versions of packages acpi-support suggests:
pn rfkill <none>
pn xinput <none>

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Stuart Barkley]

This change has broken other things (power button now shuts down
instead of giving dialog, closing lid invokes screenlock, probably
others).

It looks like the change in usr/share/acpi-support/policy-funcs is
incorrect.

Specifically:

serverpid=$(pgrep -n -u $XUSER "$PROC_NAME")

is not working as expected. This is returning no matching processes
on my system:

# pgrep -n -u stuartb gnome-settings-daemon
#

However:

# pgrep -n -u stuartb gnome-settings-
3824
# pgrep -u stuartb -l gnome
3747 gnome-keyring-d
3765 gnome-session
3824 gnome-settings-
3879 gnome-panel
3900 gnome-sound-app
3902 polkit-gnome-au
3910 gnome-screensav
3913 gnome-fallback-
#

Looks like pgrep only matches 15 characters of the process name and is
not a good replacement for pidof.

[Christoph]

On Wed, 30 Jul 2014 13:45:08 -0400 (EDT) Stuart Barkley <stu...@4gh.net>
wrote:

> Looks like pgrep only matches 15 characters of the process name and is
> not a good replacement for pidof.
>
>

Right.

> serverpid=$(pgrep -n -u $XUSER "$PROC_NAME")

pgrep needs the -f option, then the script works and power button behaves
as expected.

[Raphael Geissert]

> pgrep needs the -f option, then the script works and power button behaves
> as expected.

The use of -f changes the matching behaviour, and as such it is going
to try to match to whatever $pid says its argv[0] is, not what was
actually exec'ed.

Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

[Miroslav Urbanek]

As a workaround, I just changed "gnome-settings-daemon" to
"gnome-settings-" in /usr/share/acpi-support/policy-funcs. It fixed
the problem on my laptop.