Re: Questions regarding dbus started via systemd --user

On Fri, Jan 9, 2015 at 2:18 AM, Colin Guthrie <[email protected]> wrote:
> Cameron Norman wrote on 09/01/15 02:24:
>> On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
>> <[email protected]> wrote:
>>> On 8 January 2015 at 17:24, Simon McVittie
>>> <[email protected]> wrote:
>>>> On 08/01/15 16:03, Dimitri John Ledkov wrote:
>>>> * I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1
>>>>   and log in at the getty. How do I communicate with X11 session things
>>>>   over D-Bus, perhaps to disconnect from Telepathy without losing
>>>>   messages?
>>>> * The same, but I ssh in from another machine instead. Same question?
>>>
>>> On Ubuntu at the moment this looks in practice something like this:
>>> find UPSTART_SESSION_ID of your tty7 session, export that variable in
>>> your getty shell, then use initctl list-env ("systemctl") to list
>>> environment variables, one of them is DBUS_SESSION_BUS_ADDRESS use
>>> that to communicate with dbus.
>>
>> It would be easer if there was a variable like
>> `$XDG_RUNTIME_SESSION_DIR`, which would point to
>> `$XDG_RUNTIME_DIR/sessions/$sid`. Then you could just change that to
>> attach to a currently running session, and you could easily visualize
>> which sessions are running.
>
> In a systemd world, you already have loginctl to easily visualise which
> sessions are running. It will even tell you if they are text/tty, X11 or
> Wayland sessions, show you the processes running etc. etc.
>
> But using a SESSION_DIR like that breaks lots of other nice things, such
> as socket activation (unless you also run systemd --session instance
> which is certainly not planned!). In the user model, users will have
> their systemd --user daemon running and it can listen on all sorts of
> sockets in $XGD_RUNTIME_DIR for you and launch the actual services
> behind those sockets as needed.

I apologize my comment was a little off topic because I was referring
to setups like upstart --session, not systemd --user. Since upstart
--session (or a theoretical, and likely to remain so, systemd
--session) would be aware of that, it could perform socket activation
correctly.

>
>> It would also be nice because services
>> that do not conflict with themselves when running a second instance
>> with the same uid (not dconf, but something along the lines of a GUI
>> shell or gnome-session/upstart) could use it instead of doing their
>> own session instancing (like upstart does).
>
> While this could be attractive in some instances, I think it's ugly in
> others. Things are held together with env vars, or properties on the X11
> root window/xsettings (or equiv) and I think it becomes quite messy.
>
> With things designed properly around the user model and a few API calls
> for those apps that need to worry about sessions, means that things are
> designed better from the ground up.
>
> But to be honest, this could easily be a bikeshed debate and that's not
> really why I started this thread :D

Yeah I was suggesting simply making the session paradigm a little
cleaner by holding it together with only one env var instead of
multiple, not looking to discredit the user paradigm.

Cheers,
--
Cameron
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel