11 thoughts on “Session-Management on Linux

  1. lkraav

    Thanks for the write-up. Two things: can you elaborate on what work is being done to enable seat>0 session switching, and can you write something about how and why consolekit failed and systemd just steamrolled over it?

    Reply
    1. David Herrmann Post author

      Regarding seats != seat0, see my followup post: http://dvdhrm.wordpress.com/2013/08/25/sane-session-switching/
      I also added the links to it in this article.

      Regarding consolekit: I have honestly no idea. Maybe the reason is cgroups. They allow *reliable* process tracking which wasn’t possible before. In fact, any session-management without it is as horrible as with getsid(). But maybe consolekit was just written at the wrong time.. Who knows? logind emerged at a time at which most other stuff has been already figured out. XServer finally works without any major problems thanks to KMS (remember the VT switching in the old days?). Sessions itself have adopted dbus and provide any major infrastructure today.
      Or maybe because logind got pushed harder?

      Reply
    2. Simon

      I can’t speak about ConsoleKit specifically, but pretty much all of these system daemons have been through at least two generations – one that basically worked but not always well, then a followup that learned from the mistakes of the first attempt. HAL gave way to DeviceKit (which eventually rolled into UDEV), the first PolicyKit was replaced with polkitd, etc.

      The way I see this, ConsoleKit was the first attempt to fix this up properly, and while it worked better than what existed before, the developers learned a lot from what didn’t work. Logind is effectively the second generation of that – it’s not really that systemd displaced consolekit, so much as absorbed it…

      Reply
  2. Andrew Guertin

    “A session can start and stop processes, but it cannot escape from the session. In other words, all started processes will always belong to the session they were started in.”

    How does this play with screen, or something like reptyr? Also, is it historically true?

    Reply
    1. David Herrmann Post author

      No it’s not historically true. With old unix machines you can just run setsid() and your process will be part of a new session. However, even then, you couldn’t set your session-id directly. That is, either keep your sid or create a new one. You cannot move a process from one session to another.

      What reptyr does is moving a process from one terminal to another. As long as both terminals run in the same session, you’re fine. If both terminals run in different sessions, it will still work, but the underlying process will stay in its session.

      GNU-screen is somewhat different. Whenever you run GNU-screen, you run it from within a session. For instance if you SSH into a machine, the SSH server will start a new session for you. If you start GNU-screen from within it, it is obviously part of this session. If you run a program inside of GNU-screen, it also is part of the session. So once you disconnect from SSH, GNU-screen will keep staying around and making sure your session stays alive.
      Once you SSH into your system again, the SSH server will spawn a new session for you, independent of the old. If you now reattach to your old program via GNU-screen, it will still work. However, it will now run in a different session than your active SSH session. It forwards the screen content via GNU-screen to your session so you can interact with it. But it isn’t part of your session!

      So whether it’s GNU-screen or reptyr, all they do is re-routing TTY streams. Whether the processes on both ends of the TTY are in a different session or in the same doesn’t matter.

      Reply
  3. liam

    Is it possible to have multiple seats attached to the same session (say, for collaborative purposes)? If so, how is seat0 chosen?

    Reply
    1. David Herrmann Post author

      Seats are not attached to sessions, it’s the other way around. But no, a session cannot be attached to multiple seats. Can you elaborate a bit? I cannot follow why it would be useful.

      Reply
      1. liam

        I was thinking of seats based on the definition: “seat is a virtual object that describe a physical interface to a system” and sessions as a group of processes, designated by their having a session id, that are attached to a seat. I thought the wording I choose made the concept a bit clearer, but obviously I was wrong!
        So, let’s try this: the same session attached to two different seats, but where the monitor could be shared by both keyboards/mice.
        You say above that a device can be attached to, at most, one seat, but you also said that you can share devices across seats (like the network adaptor example) and such devices become system level. The devices that attached to the system are determined by the admin, so I wanted to know, essentially, if the monitor could become a system level device, and additional input devices could be added to an existing session such that you have multiple pointer. I’m pretty sure X can do this (via multi-pointer X, I think), but it doesn’t seem as though this can be done with what you’ve described above.
        This would be most useful in the cases of collaboration (but also extremely useful for teaching purposes) where two, or more, people are able to interact with the same screen.
        You can do this remotely with “shared” X sessions (the experience is far from great, however), but I’ve found myself with the need to do the same but with both parties using the same monitor and each with their own keyboard/mouse attached to the same pc.
        I hope that makes things clearer.

      2. David Herrmann Post author

        Ok, now I can follow. Yes, this is of course possible. What you describe is two people using one seat. I didn’t describe that use-case, you are right. On the system-level, this is handled the same as if it was only one person. So we don’t care how many people use one physical-interface and we don’t care how many pointers float on its screen. That is up to the session.

        I don’t know how X11 does it, but I know that Wayland provides support for that. It simply splits up the devices in the session into multiple “wl_seat” objects. Unfortunately, this name collides with “system seats”. They’re basically the same, but placed differently in the hierarchy. System-seats describe independent interfaces to a system. Session-seats describe different interfaces to a session.

        So if we assume two people work together in one session, they would form two different session-seats, but one system-seat.
        Generally, if someone speaks of “seats”, they talk about system-seats.

      3. liam

        Wow, it wasn’t at all obvious, to me, that the various hids attached to a pc would all be considered one seat, but I’d also not heard of session vs. system seats either, so… :)
        Thanks for explaining how logind would handle it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s