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, Informative) by Unixnut on Monday May 30 2016, @07:26PM
" In essence a CLI session would be the login process (what runs on every TTY) that then spawns a shell process once you successfully log in. Then anything you run via that shell is part of the same session, unless special commands or programs are used that effectively move one or more processes to its own session. "
So... sounds like what you are talking about are called "Process groups". A staple of Unix for decades. Why rename it to "Sessions"? Unless the goal here is to deliberately confuse and complicate things, I just don't see the point.
(Score: 0) by Anonymous Coward on Thursday June 02 2016, @05:18PM
Sessions and process groups have both existed for decades and are not the same thing. Sessions track all processes underneath a particular login. Process groups are all processes under a leader process. An example is if you run cat on a large file and it is piped into gzip. Sending a keyboard interrupt will be sent to all processes in the program group that is in the foreground (cat and gzip), but it is not sent to any groups in the background, nor the shell. However, on log out, all processes in the same session are sent the hang-up signal, regardless of whether they are in a foreground or background process group. For a better illustration, run the ps command on a running system with at least two logins and one background process running and list the processes with all the ID fields enabled (and there are a few, PPID, PGID, SID, etc.).