Bug#212991: gdm: SuspendCommand cannot be launched from the login

[Martin Samuelsson]

Sebastien Bacher @ 2004-02-29 (Sunday), 19:40 (+0100)
> $ grep Suspend /etc/gdm/gdm.conf
> SuspendCommand=/usr/bin/apm --suspend
> 
> In this case gdm check for "apm" availability to add the entry in the
> menu ...
> 
> To test the command you can try with that :
> $ grep Suspend /etc/gdm/gdm.conf | sed 's/.*=//' | sed 's/ .*//' | xargs which

% grep Suspend /etc/gdm/gdm.conf
SuspendCommand=/bin/touch /tmp/suspend_selected
% file `grep Suspend /etc/gdm/gdm.conf | sed 's/.*=//' | sed 's/ .*//' | xargs which`
/bin/touch:          ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped


I have touch installed on my system. (I have also tried with hibernate
and saytime)

When selecting Suspend from the menu, nothing seems to happen. No
/tmp/suspend_selected was created, nothing written to the gdm log.

I tried upgrading to a locally built 2.8.0.6-2, and after that it
worked. It is not that the bug is gone in that version, but I tracked
the source of the problem down to that the gdm service requires a full
restart after configuration changes.

New gdmflexiserver screens lists actions that are not possible, if they
are added to the configuration file after the backend gdm process is
started.

The correct fix would be to make sure a gdm never shows actions that the
backend can not take. A message to the log file when an action fails
would be the least to be needed to close this bug report.

I'm afraid I'm happy with finding what was causing problems for me.
Someone else will have to write the code to actually fix the bug.
--
/Martin