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: 5, Informative) by Marand on Monday May 30 2016, @07:42AM
Don't worry, it's just part of RedHat's gentle push [freedesktop.org] to make all distributions uniform by making it as hard as possible to not do things their way. Why not just roll over and let them do what's best for you?
The good news:
1) Your distro of choice may decide it's a stupid fucking default (because it is) and change it back to KillUserProcesses=no
2) If they don't, you can still set it yourself in logind.conf
3) Some distros still allow the use of alternate init systems. Debian still has sysvinit-core, for example, along with openrc, minit, upstart, runit, and probably more. I think Ubuntu users are screwed, though, because Canonical purged sysv init and most (all?) other init systems years ago to "encourage" upstart adoption. Sucks for Ubuntu users I guess, but that's what they get.
The bad news:
This will probably bite you on the ass eventually. If not now, then later, because it's another "gentle push" to make everyone do things their way or gtfo. If not this, then something else will.
At least the tmux dev didn't roll over and accept the idea of adding libsystemd and/or pam as a hard dependency, and politely told them to go do shit the right way instead of trying to push tmux into doing things the systemd way. I'm not against alternate inits, but they should at least attempt to work with the existing infrastructure (SIGHUP exists for a reason, for example) instead of demanding every process be modified to accommodate. Especially when it's a dumb fucking hack job "fix" like this.
(Score: 2) by canopic jug on Monday May 30 2016, @07:54AM
Money is not free speech. Elections should not be auctions.
(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.
(Score: 2) by Marand on Tuesday May 31 2016, @03:50AM
Follow up:
Looks like logind will still screw with processes even without the init part running, so if you have systemd-logind running at all -- a lot of desktop stuff requires it now thanks to systemd's creeping nature -- you'll need to change /etc/systemd/logind.conf as mentioned in my above comment. That, or switch to a window manager that doesn't use any of it, which should still be possible in Debian.
So, you still have to watch out for this specific issue even with an alternate init, but the general point still stands: it's fixable, hopefully your distro of choice will revert to the sane option, and if your distro hasn't completely eliminated non-systemd inits, you can swap to another init and then purge the other systemd parts if you desire.
I've had my issues with the init part, which is why I don't use it, but I gave the other portions of it a chance; so far, this is the first time the non-init parts have caused any real issue for me. It's definitely worrying but at least it's still adjustable. Heh.