SoylentNews is people
SoylentNews
The spreading of systemd continues, now actively pushed by themselves unto other projects, like tmux:
"With systemd 230 we switched to a default in which user processes started as part of a login session are terminated when the session exists (KillUserProcesses=yes).
[...] Unfortunately this means starting tmux in the usual way is not effective, because it will be killed upon logout."
It seems methods already in use (daemon, nohup) are not good for them, so handling of processes after logout has to change at their request and as how they say. They don't even engange into a discussion about the general issue, but just pop up with the "solution". And what's the "reason" all this started rolling? dbus & GNOME coders can't do a clean logout so it must be handled for them.
Just a "concidence" systemd came to the rescue and every other project like screen or wget will require changes too, or new shims like a nohup will need to be coded just in case you want to use with a non changed program. Users can probably burn all the now obsolete UNIX books. The systemd configuration becomes more like a fake option, as if you don't use it you run into the poorly programmed apps for the time being, and if they ever get fixed, the new policy has been forced into more targets.
Seen at lobsters 1 & 2 where some BSD people look pissed at best. Red Hat, please, just fork and do you own thing, leaving the rest of us in peace. Debian et al, wake up before RH signed RPMs become a hard dependency.
(Score: 3, Interesting) by Marand on Monday May 30 2016, @08:28AM
Because in this case, the discussion is about systemd's process management portion, e.g. the init system. Yes, systemd-the-project is an entire BSD-esque "core operating system" stack, but this is actually relevant to the init portion. Granted, it's about how it's overreaching and fucking up established methods of dealing with processes, daemons, etc., but it still fits.
Though, now I'm curious if the logind portion can still misbehave with regard to this setting, even without the init portion running... I'll have to test that later. So far I've tolerated the logind portion because it's been fairly inoffensive, but if it starts fucking with my processes even without the init installed, it'll probably end up purged along with the systemd init.
(Score: 1, Informative) by Anonymous Coward on Monday May 30 2016, @03:48PM
No, it's not. The init system should not be concerned with user logins/session management.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @04:29PM
Its not, directly, but it is the one part of the systemd stack that is in charge of managing cgroups.
When you log into say Gnome on a systemd distro, Gnome talks to logind, that talks to systemd-pid1, that then wraps that login in a cgroup.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @04:33PM
sysv init has handled starting login daemons since forever.
xdm/lightdm wiggled inbetween. but imho it actuyally *is* init's task to start login daemons
(Score: 0) by Anonymous Coward on Monday May 30 2016, @06:25PM
You are confusing bootup with login.
No, init do not start login "daemons". That is done by the shell via a config file read on launch.
All init does is set up the ttys and make sure login (its and actual program) runs on them.
Login is in turn in charge of making sure the username and password matches, and then fire up the shell specified in for that user. Init could not give a flying fuck what is going on during all this, unless something happens and it gets handed a orphan process by the kernel.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @07:09PM
Here's what a Gentoo inittab looks like:
It really looks like init is starting agetty (text console login) in addition to xdm (actually lxdm for me but could be kdm etc).
(Score: 0) by Anonymous Coward on Monday May 30 2016, @07:13PM
Ah i see, we are calling anything that is running in the background for daemons now.
Not really any more helpful than calling everything a service.
(Score: 2) by sjames on Tuesday May 31 2016, @06:41PM
Yes, it starts them, but that's the end of the relationship. They are not expected/required to make call backs.
If a login wants to do anything with cgroups, it should just ask the kernel itself.