One user morne than one time logged in.
Havoc Pennington
hp at redhat.com
Thu Jan 26 08:19:56 PST 2006
On Thu, 2006-01-26 at 02:48 -0500, Daniel Macks wrote:
> Actually, that is precisely what I am seeing happen with dbus. It's
> trvially easy to start a user-level daemon and fairly easy to lose
> track of its PID or screw up the killing of that pid in the logout
> process.
dbus should be started wherever the X server, gnome-session, etc. get
started, and killed in the same way. The --exit-with-session should
reliably kill the daemon if it loses an X server connection. If you
don't have an X server, I'm not sure --exit-with-session is truly
useful.
To be honest I don't really know how to make dbus work for terminal
sessions that aren't X sessions, but I also don't know of any
console-only apps that use dbus.
I don't know exactly how you are set up, though. If the situation is
ssh'ing to a remote machine and running an app displaying on a local X
session, then you need to set DBUS_SESSION_BUS_ADDRESS on the remote
machine just as you set DISPLAY. Then the remote app gets a coherent
dbus/X session with both daemons. I would not start up a separate dbus
just for the remote session.
ssh doesn't have explicit support for this right now I guess, but the
idea is that it could eventually have it.
I think it would also be sensible to implement an X property that stores
the session bus address, and have dbus spawn a slave process to read
that property if DBUS_SESSION_BUS_ADDRESS is unset. Then dbus apps would
find the bus for the X server they connect to.
Anyway, the basic idea is to just make it work like/with the X server,
same exact lifecycle and connection forwarding behavior. Console-only
sessions I just haven't thought about, and I wouldn't suggest dbus for
console-only apps right now. I think to make console-only work well
you'd probably need some kind of explicit support in the shell or login
or someplace. Based on how often utmp/wtmp/etc. are f'd up in my
experience, I'm not optimistic ...
> Is there a way to have a (cron-able) script that hunts for
> orphaned daemons? In a non-x11 terminal, --exit-with-session causes
> the daemon to exit as soon as it's created:(
There is no central registry of running instances at the moment.
If someone wanted to add some kind of "exit after 5 minutes if nothing
is connected" kind of feature, that might be a solution.
Havoc
More information about the dbus
mailing list