Hi Fredrik, Fredrik Tolf wrote: > On Sat, 2008-11-22 at 20:31 +0100, Bart Samwel wrote: >> Anyway, I don't think the suspend method is inherently broken, although >> it is broken as it is now. :-) We do things inside X sessions as well >> (such as locking all screens when suspending), so I expect it should be >> possible to get dbus-send to run inside a particular session. For >> instance, by finding the user corresponding to the console X session and >> by sourcing ~username/.dbus/session-dbus/*. > > I see. That's interesting -- I did not know of that directory or its > significance. However: > >> dbus-pm) >> if [ -x /usr/bin/dbus-send ] ; then >> + getXconsole >> + . $userhome/.dbus/session-bus/* > > I don't think that it going to work. I've got several files in there (probably > stuff left over from some unclean shutdowns) overwriting each other, so it > seems very unlikely that the last file will have the correct values. What > would > be the correct procedure here? Trying all of the files until one is found to > work?
Hmmm. That would probably be a problem. I'll have to look into that. Also, the directory can contain multiple files if you are logged in multiple times. The files do seem to mention a display in the comments, I'll have to do some research to see if I can filter out the files for the correct display, then try each and every one of them until I find one that is still live. Not pretty, but it's my only option. :-/ > Also -- I believe that you only meant that code to be used for testing, > but I can see at least two large problems with it: > > 1. This program is running as root, right? I would be very careful with > sourcing arbitrary shell commands from a users home directory then. I agree that that would be risky. However, on my system the .dbus directory is owned by root and not accessible to anyone else. So that should be no problem. (The session dbus system is apparently set up by root, and the information is passed on through environment variables; dbus-send uses environment variables to determine where --session is supposed to go.) > 2. On a system using home directories on Kerberized NFS, the script > should be able to handle root not having access to that directory > at all. That's actually something acpi-support can't handle at all -- all of the X accessing functionality also requires access to the user's home directory. I agree that a check for that would have to be added -- this was just concept code, for testing purposes. Real code would have to deal with all sorts of things. [Rant mode on] As an aside, I would love to be able to have a generic mechanism to hook into all started sessions and "inject" some functionality (like registering the appropriate session info with acpi-support), but I haven't found it yet (I have to support users who use startx as well as gdm, kdm, xdm etc. users -- it's very hard to access all of these sessions from the outside but it's even harder to hook into all of them automatically). If only I would be able to easily get all available info about sessions (other than parsing the output of w, finger or some other tool), that would already be an enormous help, but now I find myself once again without some crucial bit of information (dbus session info) which is only known in fscking *environment variables* inside the session, and not available from the outside in such a way that I can correlate it with the session itself. Aaargh!! [Rant mode off] Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
