|
|
Subscribe / Log in / New account

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 don't see how you say that there's a GNOME design bug? I saw this being repeated various times, but it has to do with systemd user sessions.

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.


to post comments

Distributors ponder a systemd change

Posted Jun 9, 2016 2:10 UTC (Thu) by BradReed (subscriber, #5917) [Link]

excellent summary, thanks.

Distributors ponder a systemd change

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).

Distributors ponder a systemd change

Posted Jun 10, 2016 0:50 UTC (Fri) by johannbg (guest, #65743) [Link] (2 responses)

"Good sodding grief... seek professional help. Seriously. "

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. ;)

Distributors ponder a systemd change

Posted Jun 10, 2016 9:31 UTC (Fri) by xtifr (guest, #143) [Link] (1 responses)

Huh?

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.)

Distributors ponder a systemd change

Posted Jun 10, 2016 11:08 UTC (Fri) by johannbg (guest, #65743) [Link]

Ah I see I was wondering why viro had not replied to that since he's one of those "I have to have the last word" type of person to gloat or further drive in his belittlement of other beings but yeah I was responding to viro comment half a sleep late last night and have accidentally clicked reply to the wrong comment.

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.

Distributors ponder a systemd change

Posted Jun 11, 2016 15:13 UTC (Sat) by krake (guest, #55996) [Link]

> 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!

My guess is that the problem is that the program is only attached to one session, or more specifically one bus.
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).

But again, this is just a guess.

Distributors ponder a systemd change

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).

Distributors ponder a systemd change

Posted Jun 11, 2016 5:46 UTC (Sat) by ras (subscriber, #33059) [Link]

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

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.

Distributors ponder a systemd change

Posted Jun 12, 2016 15:37 UTC (Sun) by davidstrauss (guest, #85867) [Link] (1 responses)

> systemd took over DBus.

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.

Distributors ponder a systemd change

Posted Jun 12, 2016 19:43 UTC (Sun) by johannbg (guest, #65743) [Link]

Kdbus is dead and the code that could use it in systemd is being removed to ensure it will never be used so kdbus and systemd is an certain "will not happen in the future".

Distributors ponder a systemd change

Posted Jun 13, 2016 11:34 UTC (Mon) by gb (subscriber, #58328) [Link] (1 responses)

If there are gnome processes requiring cleanup why in bloody hell this should have influence on anything else? Just ask dbus to list processes connected to it AND 'gnome' and kill em.

System-wide change is clearly not necessary here!

Distributors ponder a systemd change

Posted Jun 13, 2016 13:33 UTC (Mon) by micka (subscriber, #38720) [Link]

Gnome is just an example of such program, but as some people like to hate gnome, the simple fact that the name appeared somewhere makes it the center of grief (something it shares with systemd).
And I suppose not all such processes use dbus.

Distributors ponder a systemd change

Posted Jun 15, 2016 2:57 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> KillUserProcesses is implemented, and GNOME's problem is solved.

The flag was implemented way long ago (before 2011). This is about changing the default.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds