Distributors ponder a systemd change
Distributors ponder a systemd change
Posted Jun 8, 2016 11:12 UTC (Wed) by ras (subscriber, #33059)In reply to: Distributors ponder a systemd change by ovitters
Parent article: Distributors ponder a systemd change
I have trouble distinguishing between GNOME and systemd. To the extend they are separate projects, you may be right.
Roughly what happened was:
1. In the beginning there was there login. Every process started after login was a child of it, the kernel used a very simple process to track those children and so it was easy to clean up on logout.
2. Then X and xdm replaced login, but every process was a child of xdm, and cleaning up on logout remained simple.
3. Then there was GNOME, and gdm, and later gdm spawned corba. Things were rapidly getting more complex, but nonetheless everything was a process child of gdm and so cleaning up on logout was till simple.
4. GNOME moves to dbus.
5. systemd takes over dbus.
6. systemd takes over session management - primarily via logind.
7. GNOME immediately adopts logind, causing much angst on Debian because it meant the default desktop required you to use systemd.
8. GNOME starts uses dbus to lazily start services.
9. systemd starts dbus under a separate process tree (the one under systemd --user, as opposed to the one started by gdm).
10. GNOME notices if the user logs in twice, they start services such as the evolution-address-book twice. Seems inefficient. They share services between two login sessions. For some services.
11. Consequently keeping track of what session owns what process becomes hard. Some things aren't killed properly when the sessions logout. Since logind is tracking the sessions, seems like a good idea to make it the systemd mob's problem. KillUserProcesses is implemented, and GNOME's problem is solved.
12. But no one is turning KillUserProcess on so GNOME sessions are still leaving services running. So systemd-230 changes it to default to be on.
And so here we are. If you tell me it's really systemd's at fault then so be it - for me it like picking between two peas in a pod.
Posted Jun 9, 2016 2:10 UTC (Thu)
by BradReed (subscriber, #5917)
[Link]
Posted Jun 9, 2016 23:47 UTC (Thu)
by xtifr (guest, #143)
[Link] (4 responses)
Interesting. That definitely makes sense.
However, that suggests another possible approach to this problem. Instead of having evolution-address-book ignore sighup (which is what I assume it's doing now, so that it can survive one session's ending), have it respond to sighup by checking how many sessions it's attached to! If the number is one (or less), it can shut down gracefully, but if the number is higher, then it knows it should ignore the signal!
Of course, this would mean that the programs would have to know how many sessions they were attached to, but isn't that exactly the sort of thing dbus was created to handle?
This would place the problem where it belongs (on Gnome processes which want this session-sharing feature), rather than on unrelated software (screen/tmux, etc., anything launched via nohup, and unknown number of "little" homerolled background persistent thingies).
Posted Jun 10, 2016 0:50 UTC (Fri)
by johannbg (guest, #65743)
[Link] (2 responses)
What an excellent idea we can go together I for my chronic depression and you for your alter ego which gets you off by judging, putting down or belittling other people in comment section and on mailing lists. ;)
Posted Jun 10, 2016 9:31 UTC (Fri)
by xtifr (guest, #143)
[Link] (1 responses)
Oh, you replied to the wrong post. Never mind. It happens.
(For a second I thought you were suggesting that my proposal was extremely crazy. Which it might be, but a quick skim showed me the post you were trying to respond to.)
Posted Jun 10, 2016 11:08 UTC (Fri)
by johannbg (guest, #65743)
[Link]
I would have spotted it if the sites comment editor would be posting what's being responded to above not below itself ( it arguably should do so in atleast above the comment preview so the preview is in full context with what's being responded to ).
Sorry for the mistake.
Posted Jun 11, 2016 15:13 UTC (Sat)
by krake (guest, #55996)
[Link]
My guess is that the problem is that the program is only attached to one session, or more specifically one bus.
But again, this is just a guess.
Posted Jun 10, 2016 11:27 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
This is looks like a plausible theory but it's most definitely a wrong one. I've seen lingering GNOME processes left behind years before systemd was even imagined. I'm not really sure what/when spawned them (gvfs with it's use of FUSE was the main culprit, but I think there were others, too), but that happened way earlier than systemd introduction. IOW: systemd solves the real and sizable problem which predates it, although it's not clear if that's the best solution available (well, it's certainly the best available solution in a sense that it's the only one that works, but it does not mean it couldn't be better).
Posted Jun 11, 2016 5:46 UTC (Sat)
by ras (subscriber, #33059)
[Link]
So have I. Yes, it's definitely the same symptom. But the same symptom does not mean the underlying cause is the same - particularly in software.
Posted Jun 12, 2016 15:37 UTC (Sun)
by davidstrauss (guest, #85867)
[Link] (1 responses)
systemd *uses* DBus and provides its own DBus client library. It's basically what cURL's relationship to Apache is.
Just in case you're thinking about kdbus, it's not part of systemd, hasn't happened yet, and may or may not happen in the future.
Posted Jun 12, 2016 19:43 UTC (Sun)
by johannbg (guest, #65743)
[Link]
Posted Jun 13, 2016 11:34 UTC (Mon)
by gb (subscriber, #58328)
[Link] (1 responses)
System-wide change is clearly not necessary here!
Posted Jun 13, 2016 13:33 UTC (Mon)
by micka (subscriber, #38720)
[Link]
Posted Jun 15, 2016 2:57 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
The flag was implemented way long ago (before 2011). This is about changing the default.
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
I.e. previously each login had its own D-Bus session (session bus), but now there is one D-Bus "session" per user (user bus).
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
And I suppose not all such processes use dbus.
Distributors ponder a systemd change