wpasupplicant sleep action broke suspend on Jaunty

I confirm this problem.

This is a script provided by Debian, does not affect upstream.

pm-utils is not actually supposed to supply a second argument to the scripts.

Whoops, it is actually supposed to get two arguments. From HOWTO.hooks:

  The actual sleep method being used will be passed as the second parameter --
if your hook needs to handle suspend-hybrid (or any other platform-specific
sleep method), it should examine the second parameter.

This bug was fixed in the package wpasupplicant - 0.6.6-1ubuntu1

---------------
wpasupplicant (0.6.6-1ubuntu1) jaunty; urgency=low

  * debian/ifupdown/action_wpa.sh: pm-utils now supplies a second
    argument to the hooks, thus telling ifplugd and pm-utils apart by
    the number of arguments does not work any more. Fix up the script
    to just evaluate the arguments themselves, to work with current
    and older pm-utils. This unbreaks suspend. (LP: #307312, forwarded
    to Debian #508526)

 -- Martin Pitt <email address hidden> Thu, 11 Dec 2008 16:57:31 -0800

On Fri, 2008-12-12 at 00:48 +0000, Launchpad Bug Tracker wrote:
> You have been subscribed to a public bug:
>
> This is a brand new defect which was just introduced in the past day or
> so. Suspend no longer works, and the following can be found in /var/log
> /pm-suspend.log:
>
> ===========================================
> /usr/lib/pm-utils/sleep.d/00powersave suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/01PulseAudio suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/48hid2hci suspend suspend: E: core-util.c: Home directory /root not ours.
> E: pacmd.c: No PulseAudio daemon running
> not applicable.
> /usr/lib/pm-utils/sleep.d/49bluetooth suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/50ntpd suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/75modules suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/90chvt suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/90clock suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/94cpufreq suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/95anacron suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/95led suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/96laptop-mode suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/98smart-kernel-video suspend suspend: success.
> /usr/lib/pm-utils/sleep.d/99video suspend suspend: success.
> /etc/pm/sleep.d/action_wpa suspend suspend: action_wpa: uknown ifplugd arguments: suspend suspend
> Returned exit code 1.
> Thu Dec 11 18:18:17 EST 2008: Inhibit found, will not perform suspend
> Thu Dec 11 18:18:17 EST 2008: Running hooks for resume
> ===========================================

Please move the 95anacron and 96laptop-mode hooks out of the 90 - 99
range. See HOWTO.hooks for the ordering convention.

Also, action_wpa should have a numeric prefix -- right now it will run
after NetworkManager has gone to sleep, interfaces possibly taken down,
and network card driver modules unloaded. Needless to say, that might
affect the functioning of the hook.

> This was broken by a recent wpasupplicant change. If you add
>
> exit 0
>
> to the top of /etc/pm/sleep.d/action_wpa (a symlink to
> /etc/wpa_supplicant/action_wpa.sh), suspend works again.
>
> ** Affects: pm-utils (Ubuntu)
> Importance: High
> Assignee: Martin Pitt (pitti)
> Status: In Progress
>
--
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

vlowther [2008-12-12 2:02 -0000]:
> Please move the 95anacron and 96laptop-mode hooks out of the 90 - 99
> range. See HOWTO.hooks for the ordering convention.
>
> Also, action_wpa should have a numeric prefix -- right now it will run
> after NetworkManager has gone to sleep, interfaces possibly taken down,
> and network card driver modules unloaded. Needless to say, that might
> affect the functioning of the hook.

Can you please file separate bugs for this, preferably directly in
Debian, or in Launchpad? This bug is unrelated, and already fixed.

> Also, action_wpa should have a numeric prefix -- right now it will run
> after NetworkManager has gone to sleep, interfaces possibly taken down,
> and network card driver modules unloaded. Needless to say, that might
> affect the functioning of the hook.

action_wpa requires the UNIX control socket to send the disconnect command to wpa_supplicant, thus it does not affect the wpa_supplicant process which NM starts via D-Bus, it only tries to make things smoother for people who use /etc/network/interfaces

If numeric sequence numbers are to be used with hooks, it would be nice to see mention of this in pm-utils documentation.