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: 0) by Anonymous Coward on Monday May 30 2016, @03:59PM
user processes started as part of a login session are terminated when the session [exits]
Sorry but, what the fuck is a session? I thought my login prompt just checks my password before setting uid/gid/env/workingdir and execing my shell? What if I don't have dbus? I don't understand any of this, what's going on here?
(Score: 2) by Scruffy Beard 2 on Monday May 30 2016, @04:44PM
Sorry but, what the fuck is a session? I thought my login prompt just checks my password before setting uid/gid/env/workingdir and execing my shell? What if I don't have dbus? I don't understand any of this, what's going on here?
Good question. As far as I can tell, they are trying to emulate the (useful) Windows XP "switch user" functionality.
A saw a video a while ago where the behaviour of changing permissions to things like the audio device (upon login) was being criticized. Pottering interrupted the presenter. explaining that there was no other way to provide accessibility features than to run things like pulse audio before the user even logs in. My google-fu fails me at the moment.
(Score: 2, Informative) by Anonymous Coward on Monday May 30 2016, @06:31PM
Sounds like Datenwolf's presentation on unix cruft.
https://www.youtube.com/watch?v=ZTdUmlGxVo0 [youtube.com]
Note that it is perhaps the only presentation during a Linux related conference where the presenter have been continually interrupted by someone in the audience making "corrections", never mind having said "correcter" step up on stage at the end.
And yes, one of their goals is trying to create a multiseat setup out of a desktop PC. This by grouping various hardware (keyboard, mouse, screen, possibly more) and then tying that group to a user based on the keyboard used for logging in.
They are effectively trying to recreate physical terminals from multiple independent hardware attached to a single computer.
(Score: 2) by Arik on Tuesday May 31 2016, @04:10AM
The man is such a jackass. I honestly can't understand why he wasn't simply banned from every meeting and email list of any importance a decade or more ago.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Wednesday June 01 2016, @05:21PM
Because he works for RedHat and they have all the money. There probably isn't a single Linux related conference that RedHat doesn't sponsor to get their name on it. If conferences banned their employees, that sweet, sweet cash would dry up. But you can be sure that his boss at RedHat told him to calm down because he has been better of late. Nobody wants customers leaving and going somewhere else due to the behavior of a single employee, regardless of who it is.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @06:21PM
Session is an abstract concept that group processes.
The Linux kernel actually have a notion of sessions internally, but it is largely transparent to most users.
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.
A session effectively ends when the shell process at the root of the tree exits, as then every child process is given the HUP signal, and should exit.
Similarly, a X session ends when the X server (keep in mind that in X terminology server and client is reversed) exits.
What you have is systemd creating its own notion of what is a session, and not giving a damn about what the kernel thinks.
(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.).