Cameron Norman wrote on 09/01/15 02:24:
> On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
> <dimitri.j.led...@intel.com> wrote:
>> On 8 January 2015 at 17:24, Simon McVittie
>> <simon.mcvit...@collabora.co.uk> 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.
This makes things a lot nicer and should make startup much faster too as
all these agents that are started now can be left until they are needed.
If you introduce this SESSION_DIR concept then this isn't possible.
Now that's not to say each of the things cannot survive in a session
context. It's entirely possible for things like ssh-agent or gpg-agent
etc to run once but internally handle multiple sessions. They can easily
ask logind to which session a calling process belongs (man 3
sd_pid_get_session) and hook into the appropriate gui component.
So yes, the user model might mean changing some plumbing components to
properly support multiple sessions properly, but to be honest many such
components don't work properly with multiple sessions anyway (some do,
but others don't).
I think with clarity going forward, things can be designed with clear
boundaries in mind rather than the myriad of corner cases Simon already
outlined (many of which simply don't have correct answers - it can be
opinion based. I think we need clarity here - whether some of us agree
with the decision or not, so that there are no opinions left - just
specifications!)
> 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
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
