After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 333031 - run user scripts before doing stuff
run user scripts before doing stuff
Status: RESOLVED OBSOLETE
Product: gnome-power-manager
Classification: Deprecated
Component: gnome-power-manager
SVN TRUNK
Other All
: Normal enhancement
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2006-03-01 19:31 UTC by David Zeuthen (not reading bugmail)
Modified: 2020-11-07 12:18 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
simple_gaim_ctrl.py (1017 bytes, text/plain)
2006-12-23 16:01 UTC, Laurento Frittella
Details

Description David Zeuthen (not reading bugmail) 2006-03-01 19:31:33 UTC
It would be useful if g-p-m would run user defined scripts before doing stuff. See 

 http://xvsxp.com/power/
 http://xvsxp.com/power/images/ups33.jpg
 http://xvsxp.com/power/images/ups-configuration.jpg

for how OS X and Windows XP does this. I think just having

 /etc/gnome-power-manager/admin-scripts/<X>.d/

directories where X = {suspend, hibernate, shutdown, battery_critical,
on_ups_power} is sufficient. Needs some thinking about exactly what actions are
useful. Could pass reasons and hal udi's in the environment. 

Should run these scripts in the context of the user (e.g. pass $DISPLAY and
$DBUS_SESSION_BUS_ADDRESS) so they can interact with the desktop. 

Run all scripts in sequence (alphabetically) one after one.

If a script returns something != 0 it means cancel the action. Also means other
scripts following the one that returns != 0 isn't called.

If scripts need root the admin can setuid himself.

g-p-m should ship with no scripts whatsoever - this should _only_ be used by the
admin.
Comment 1 Richard Hughes 2006-03-02 19:05:09 UTC
>/etc/gnome-power-manager/admin-scripts/<X>.d/

per-system (etc) or per-user (/home/foo/.gnome)?

>Run all scripts in sequence (alphabetically) one after one.

You do this already in HAL, and I was wondering if you can point me towards how you did this. I'm not lazy, I'm busy. Honest!

>g-p-m should ship with no scripts whatsoever - this should _only_ be used by
>the admin.

What about some sample code, that is commented out, like

#uncomment and change the email to your admin email address to send an email
#fooo richard@hughsie.com

Richard.
Comment 2 David Zeuthen (not reading bugmail) 2006-03-02 19:10:46 UTC
> per-system (etc) or per-user (/home/foo/.gnome)?

It's an admin feature so per-system.

> > Run all scripts in sequence (alphabetically) one after one.
> You do this already in HAL, and I was wondering if you can point me towards how
> you did this. I'm not lazy, I'm busy. Honest!

We don't do this anymore in hal... However look at hal/hald-runner for info on how to spawn executables...

> What about some sample code, that is commented out, like

No, I don't think we don't want the overhead. If the admin uses this feature he better knows what he is doing. Suggest to include examples in the user guide though.

Comment 3 Richard Hughes 2006-03-10 19:11:05 UTC
Okay, I've been thinking about how and why to impliment this.

What stuff could the user want in the scipts to run at shutdow, suspend, ups_low etc? The notion of having scripts to configure is sort of odd, considering the whole idea of this g-p-m/hal thing is to "just work".

The only actions that I can comprehend are:

[*] Email someone of the event

The rest of the stuff in my head (stopping and starting services, telling evolution we are going to suspend, etc) should just work without using scripts using the registration interface we talked about.

You got any more ideas for examples, so I can justify adding a whole chunk of new code?

Thanks.
Comment 4 Scott James Remnant 2006-09-20 00:43:59 UTC
Sorry to blow my own trumpet here, but this is exactly the kind of thing upstart is designed for.
Comment 5 Richard Hughes 2006-09-20 14:23:25 UTC
Umm. I don't get how upstart could help us in this regard...
Comment 6 Scott James Remnant 2006-09-20 17:05:28 UTC
This is exactly what it's designed to do, run user scripts (or sysadmin scripts, or package scripts) on system events.  Rather than deal with with iterating a directory yourself, building an environment, spawning a process, dealing with killing it, etc. you would just send an event to upstart (via dbus, if you like) and have it take care of that.
Comment 7 Laurento Frittella 2006-12-13 15:49:13 UTC
This should be useful for me because...
I want to send messages to gaim to disconnect all accounts on suspend and to reconnect them on resume using DBus. I wrote a working script in python but if I use OnSuspend and OnResume in the hibernate configuration to start it, the script runs with root privileges and it doesn't work as it should (I want to interact with some applications using the DBus session of the user that runs g-p-m).
Comment 8 Richard Hughes 2006-12-23 15:53:09 UTC
Laurento, can you attach your scripts? I can add them to gnome-power-manager if you wish - I already include actions to deal with NetworkManager and gnome-screensaver.
Comment 9 Laurento Frittella 2006-12-23 16:01:34 UTC
Created attachment 78833 [details]
simple_gaim_ctrl.py

Sure! Here you are.

These are the script options:
  --version         show program's version number and exit
  -h, --help        show this help message and exit
  -c, --connect     Connect ALL Gaim account
  -d, --disconnect  Disconnect ALL Gaim account

You can combine -c and -d (-cd or -dc) to reconnect all account if you want.
Comment 10 Richard Hughes 2007-01-21 21:06:51 UTC
Okay, I think it's best we just provide a DBUS api that applications get notifiaction hooks for. I'll talk to the GAIM guys and see what they think of the idea.
Comment 11 André Klapper 2020-11-07 12:18:52 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all
old feature requests in Bugzilla which have not seen updates for many years.

If you still use gnome-power-manager and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-power-manager/-/issues/

Thank you for reporting this issue and we are sorry it could not be implemented.