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] the scripts the scripts
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 higher-level package. 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 ***