Bug 111958 - acpi power script
Summary: acpi power script
Status: CLOSED DUPLICATE of bug 169476
Alias: None
Product: Fedora
Classification: Fedora
Component: acpid (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-11 23:05 UTC by Need Real Name
Modified: 2015-03-05 01:13 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-10 13:48:55 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
the scripts (3.02 KB, application/octet-stream)
2003-12-11 23:08 UTC, Need Real Name
no flags Details
enable sleep mode (241 bytes, patch)
2005-05-26 02:15 UTC, petrosyan
no flags Details | Diff

Description Need Real Name 2003-12-11 23:05:29 UTC
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.

Comment 1 Need Real Name 2003-12-11 23:08:30 UTC
Created attachment 96486 [details]
the scripts

the scripts

Comment 2 Bill Nottingham 2003-12-11 23:18:42 UTC
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?

Comment 3 Need Real Name 2003-12-12 08:31:00 UTC
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

Comment 4 Bill Nottingham 2005-03-16 22:34:19 UTC
*** Bug 81142 has been marked as a duplicate of this bug. ***

Comment 5 petrosyan 2005-05-26 02:15:25 UTC
Created attachment 114862 [details]
enable sleep mode

here is a patch that enables the sleep mode (suspend to memory)

Comment 6 Aaron Gaudio 2005-06-19 00:41:03 UTC
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.

Comment 7 Linus Walleij 2006-01-05 21:27:58 UTC
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.

Comment 8 Aaron Gaudio 2006-01-06 00:15:23 UTC
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).

Comment 9 Phil Knirsch 2006-02-10 13:48:55 UTC
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 ***

Note You need to log in before you can comment on or make changes to this bug.