Systemd 230 Is Upsetting Some Over Its KillUserProcess Setting

[bkor]

EXACTLY. tmux behaving correctly, using what exist (daemon() et all) and because dbus and GNOME are not cleaning up after themselves in comes systemd and sets as default the "kill everything" why the hell not fix the actual problem.

You're claiming that dbus and GNOME aren't cleaning up and thus this change is triggered by this behaviour. Eventhough these parts of GNOME and dbus existed before systemd was started. In brief: you're bullshitting. GNOME (gnome-session) does handle child processes correctly as well as dbus. Either provide clear evidence or maybe just simple stop spreading misinformation about dbus and GNOME.

[carewolf]

You're claiming that dbus and GNOME aren't cleaning up and thus this change is triggered by this behaviour. Eventhough these parts of GNOME and dbus existed before systemd was started. In brief: you're bullshitting. GNOME (gnome-session) does handle child processes correctly as well as dbus. Either provide clear evidence or maybe just simple stop spreading misinformation about dbus and GNOME.

They have always done this. It is usually not that big a deal, it just means you can log in faster after logging out. The resources used are minimal, and people were not even sure it was a bug. Also without systemd there would be no mechanism to do this correctly, the helper processes need to detach themselves to not get killed along with their launcher. Being detached, they do not get cleaned up automatically without some kind of a session system, and Linux didn't have a good standard for that before systemd.

[starshipeleven]

>This was raised 5 years ago and just IGNORED ...

It wasn't "raised".
"change how daemon() is implemented" is very vague and gives NO guarantee that it would work better, and it would probably cause major breakage all-around since they will probably have to change things and ALL programs under the sun that use it may be affected.

You just found a guy that wants to redesign everything around his stuff, but since he is calling down UNIX phylosophy and shit you feel more attuned.

The little issue is that he isn't making an init system, so he does not get to decide about these matters.
kernel->init->userspace libraries this is the chain of command.

[Naib]

You're claiming that dbus and GNOME aren't cleaning up and thus this change is triggered by this behaviour. Eventhough these parts of GNOME and dbus existed before systemd was started. In brief: you're bullshitting. GNOME (gnome-session) does handle child processes correctly as well as dbus. Either provide clear evidence or maybe just simple stop spreading misinformation about dbus and GNOME.

https://bugs.freedesktop.org/show_bug.cgi?id=94508

https://github.com/systemd/systemd/issues/2900

[Naib]

it wasn't "raised".
"change how daemon() is implemented" is very vague and gives no guarantee that it would work better, and it would probably cause major breakage all-around since they will probably have to change things and all programs under the sun that use it may be affected.

You just found a guy that wants to redesign everything around his stuff, but since he is calling down unix phylosophy and shit you feel more attuned.

The little issue is that he isn't making an init system, so he does not get to decide about these matters.
Kernel->init->userspace libraries this is the chain of command.

unix has always worked in the same way. If you logout then programs are
killed, unless they daemonize (which is pretty standard by now) in which
case they sit around until you kill them.

and sysadmins of course can kill your stuff whenever they like.

so, why is systemd different here?

[float]

Since nobody posted it yet

https://github.com/tmux/tmux/issues/428

[starshipeleven]

(citing someone else)
unix has always worked in the same way. If you logout then programs are
killed, unless they daemonize (which is pretty standard by now) in which
case they sit around until you kill them.

and sysadmins of course can kill your stuff whenever they like.

so, why is systemd different here?

Not all programs that should die are killed on logout due to various reasons, and there is the issue of zombie processes and (in the future) of malware.

systemd is shifting the "program dies because it's a child of X and X is killed" paradigm which can and does fail to "systemd kills all stuff that isn't allowed to live when X is killed" which has less chances to fail since systemd is an active system.

This is in line with systemd project's idea of hardening things, and of providing a init system that is active and uses its init power to actually do things instead of just sitting on it.

[unixfan2001]

Naib

What is your point exactly? It's always been done poorly and flat out wrong, so let's not break the expected behaviour by actually fixing the pipeline?

[Naib]

Naib

What is your point exactly? It's always been done poorly and flat out wrong, so let's not break the expected behaviour by actually fixing the pipeline?

My point is the cavalier approach by SystemD developers (they set it to default, by and by whether distro’s packages that) to a Linux system, coupled with the incompetence of GNOME/DBUS to fix their own bugs is resulted in the arrogant request’s .

Daemon(3) has existed for a long time, it is the established way for a process to demonize itself. This works, this is understood, there is no reason to break this…. Unless you chuck in incompetent and arrogant developers. its not "flat out wrong" as you state.

You talk about a broken pipeline yet it was broken by GNOME/DBUS unable to sort out the exit sequence NOT via tmux, nohup, bg, screen, etc…

You want to talk about broken? Systemd makes use of SIGKILL to clean up https://www.freedesktop.org/software...temd.kill.html . I am guessing you are not aware as to why this is bad…

https://web.archive.org/web/20110730051506/http://partmaps.org/era/unix/award.html#uuk9letter

No no no. Don't use kill -9.
It doesn't give the process a chance to cleanly:
1) shut down socket connections
2) clean up temp files
3) inform its children that it is going away
4) reset its terminal characteristics
and so on and so on and so on.
Generally, send 15, and wait a second or two, and if that doesn't work, send 2, and if that doesn't work, send 1. If that doesn't, REMOVE THE BINARY because the program is badly behaved!
Don't use kill -9. Don't bring out the combine harvester just to tidy up the flower pot.

[PuckPoltergeist]

Nice, with 'loginctl enable-linger' the orphaned kf5 processes after a logout survive again. But the screen session I've opened is killed.