One user morne than one time logged in.

Daniel Macks dmacks at
Wed Jan 25 23:48:13 PST 2006

On Thu, Jan 26, 2006 at 01:34:14AM -0500, Havoc Pennington wrote:
> On Wed, 2006-01-25 at 17:53 -0500, Daniel Macks wrote:
> > 
> > There are lots of login routes and dbus usages that don't rely on the
> > concept of a "desktop session". How about servers that are accessed
> > via remotely (say I open two ssh connections), or OS X, where the
> > "local machine shell" widget does not have the concept of a session or
> > a startup script from which to launch the daemon?
> dbus is very explicitly designed for only two use-cases; one is a
> GNOME/KDE style "desktop session" and the other is the systemwide bus on
> Linux or similar systems. Anything else is bonus, only if it doesn't
> break or complicate the core two use cases. There are plenty of fully
> generic IPC systems in the world already.

I'm coming at this as a user and sysadmin who needs to install and
manage software whose authors have chosen to use dbus, not as a
programmer looking for an IPC solution.

> >
> What you describe there is how gconfd originally worked, it has too many
> problems and we had to drop it.
> - having a daemon persist after logout breaks multiuser systems pretty 
>   badly

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. 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:(

> per-user is not useful if it has weak "maybe" semantics. It's only
> useful if it's absolutely guaranteed to produce a per-user singleton,
> and that is not possible if you can only assume a shared homedir.

Point well taken.


Daniel Macks
dmacks at

More information about the dbus mailing list