The archive (that will follow) contains scripts that handle the logout
process for gnome, xfce and fail safe. Gnome is handled almost by the
book while xfce and xterm are killed. A handler for KDE is still
needed. To do that a script exposing 2 functions have to be exposed.
One that counts how many KDE sessions exists and one that does the
actual logout. This is done by extending COUNT_FUNCTIONS and
LOGOUT_FUNCTIONS (see the handlers). The logout function returns 0 on
success, 1 on failure (when is invoked but the environment does not
point to a KDE session) and 2 on abort. For the logout function the
following environment will be set:
USER - the user name
DISPLAY - the display variable (without :)
VT - the virtual terminal
PID - the process id of the session
There are still some problems.
1. gnome-session-save --kill does not return anything, so if the user
cancels the logout there is no way to know but by checking if the
session is still there. So I've set a time out for that, but if the
logout takes more time the shutdown will be aborted. This might easily
be the case if an user has started some programs that does not handle
the "save state" thing and a prompt appears.
2. gdm might change the active terminal on re-spawning while an logout
dialogue might wait for user input. It might be solved if it would be
a way to find out which is the virtual terminal where it will spawn,
or by disabling gdm.
Created attachment 96486 [details]
I may be missing something, but what is the purpose of these - what
problem are they solving? And what does it have to do with acpid?
well even if it was posted as an enhancement, acpid does come with an
sample script which shutdowns the system without paying any attention
about what a user might forgot to close
*** Bug 81142 has been marked as a duplicate of this bug. ***
Created attachment 114862 [details]
enable sleep mode
here is a patch that enables the sleep mode (suspend to memory)
Here's my $0.02:
I just upgraded to Fedora Core 4 (from FC3) and I was quite surprised when I
pressed my laptop's power button and it began to both shutdown and suspend to
disk (suspend won, then once I restored, the shutdown completed :-/).
The problem was that I already had an acpid configuration, and the sample.conf
provided in the acpid rpm added an additional handler for my power button (to
shutdown). Now I suspect I'll have to remember to delete sample.conf every time
acpid gets upgraded.
In my opinion, there is no good way to tell if sample.conf (or any other
'default' acpid configuration) is stepping on the toes or otherwise interfering
with an existing acpid configuration. Therefore, I propose that sample.conf be
moved into the documentation for acpid (/usr/share/doc/acpid*) instead of into
/etc/acpi, so that it takes a consious act to apply it. Or, if you want to get
more fancy, create a post-install script for acpid which checks for the
existence of scripts in /etc/acpi and only copies in the defaults/sample if
there are not already any files in there.
I am under the impression that all of these things get handled by
gnome-power-manager which is in devel now. (It installs ACPI scripts
too and communicate with everything using D-BUS.) I don't know if
that program integrates well or at all with KDE however.
I am in favor of letting an optional add-on package (such as
gnome-power-manager) install its own default handlers into the acpi directory.
My assumption is that if the user were using gnome-power-manager, he or she
would not have to manually configure acpid, but rather configure the
However, I do not think the acpid package should install the example ones
(unless all they do is say log a message).
I've already put a related bug in investigate where gnome-power-manager and
acpid conflict who shuts down the system.
The idea is to check in the default acpid script if X11 and/or
gnome-power-manager is running and won't do anything if thats the case.
Read ya, Phil
*** This bug has been marked as a duplicate of 169476 ***