There was basically a choice to be made: (a) Fix bugs in software that left processes unintentionally running past logout, (b) Allow users to opt in to unconditionally killing processes on logout, (c) Interactively ask users which process groups to keep, or (d) BREAK ALL THE THINGS.
Only an idiot, an asshole, or an arsonist chooses (d), and I am inclined to think it's one of the latter two when they admit to knowing it will break things.
nohup is only one way to perform the steps that allowed a process to keep running after the user logged out. It isn't hard to do the same things within a program when and if it was necessary. systemd has broken programs that do that.
For example, take a daemon that has command-line switches to make it check its configuration files for obvious problems versus running in the background. With this systemd change, the only fine-grained way to make it work the way it was intended was to add a lot of command-line noise to places where it is started in its daemon mode. The global and per-user switches will leave buggy software still running when the user logs out.
People already did the work to keep their processes alive after their session leader exits. systemd is now breaking that work, apparently because GNOME's developers cannot figure out how to fix their own bugs, and must rely on systemd to clean up the cow droppings they leave all over the place.
A better person than you would be ashamed and admit their error and ignorance, rather than lamely accusing me of bad faith just because you can't answer the question.
The "alternative" mechanism you describe just isn't an alternative, it is orthogonal to the behavior under question. Again: Why is it okay to break the thing that has worked essentially as long as UNIX has existed just because an independent mechanism (for doing something entirely different) exists?
Why is it okay to break the 40+-year-old method for preserving a process after the login shell exits just because there is an orthogonal mechanism for applying resource quotas?
It is not "tightening up" security. There was already a little configuration step that made things work as desired. "nohup" was one way to do that, but processes could also do autonomously. Why do systemd tools keep wanting to break things that work?
Apparently you know nothing about the principle of least surprise.
What is more obvious, more common, and more widely understood: "nohup foo &" or "systemd --magic-grok --yes-i-want-this-to-stick-around --user --of-course-i-mean-user foo"? Which one has been the standard way to keep things running after a login shell exits for about 40 years?
If non-buggy software is running in its own process group, that's a pretty darn good indication to a competent sysadmin that it is meant to hang around.
That GNOME software is buggy should be news to nobody.
I can understand wanting to apply resource quotas to some subset of processes. What I don't understand is tying that to a user's interactive session, much less using additional mechanisms to reproduce sessions/process groups, as systemd is doing in this case. It seems to me that you're defending using cgroups, which is only coincidentally related to systemd's behavior.
The standard says "If the process is a controlling process, the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process." No action required by that controlling process, or even discretion about it.
No, it is *not* self-evident that cgroups are an improvement for login sessions. For virtualization, sure, they make sense -- but I am unconvinced that the same kind of resource quotas make sense for login sessions.
"It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so."
No, it is not more complicated than what I said. A typical session leader does not kill the other processes in its session (or even process group). At some point -- say, because the login shell (which was the process group/session leader) exited -- the kernel sends SIGHUP to all the processes in the session, and the default handler for this terminates the processes in the session, and thus the session.
How is using cgroups an improvement over the POSIX way of doing things?
/. must have associated my comment with the wrong one of your spammy comments. I was responding to your assertion that now only "legitimate" processes will be running when you log out. Clearly, you don't have a clue about why that is *not* a pro-security approach.
You... might want to understand what you're criticizing before shooting off your mouth. Under POSIX, the login session lasts until the last process in it terminates, not until the login shell terminates.
The fact that they documented their broken choices, and incorrectly label them "very conservative", does not change the fact that the changes are stupid and break well-considered, long-standing behaviors in order to clean up after other software that is equally stupid and broken.
Hello, electronic computers already made us bad at math. There used to be lots of people who made their livings by adding columns of numbers, doing multiplication and division and logarithms! Now those things are done by people only as curiosities, and basically nobody could make a living doing them. QED, or GED, or whatever.
It was actually meant as a mostly facetious example of why it isn't weird to use a comma in place of the word "and". I guess Americans' senses of humor are too subtle for modern Brits.
If he has gone regularly in the past, this incident will probably not change his habits, and if he doesn't go there regularly, him staying away won't be a big hit to their revenue. I'm wondering why he thinks the franchisee (or chain owner) should care enough either way to replace several workers with a manager.
Don't get me wrong: I would love it if competent managers were on duty at practically all customer-facing establishments. The flirting employees were wasting the customer's time and the employer's money. But I don't see the incentives lining up to fix the problem: In the places where the economics make sense, they probably do have decent managers on duty; in places where return traffic is infrequent or inelastic, and where cost is a large competitive factor, good managers will be less common.
What would good management do in that case, except cost as much as two or three of those teenagers? The chain already has your money, so what are you going to do that impacts their bottom line?
Don't forget the repair techs. They'll probably be on H-1B visas, though, because the only BurgerFlip3000 repair certification program will be in Goa or someplace.
That $0.10/person extra works out to, what, $2/hour for the server? During relatively busy shifts? I don't think that's in line with minimum wage laws, even if the customers tip (adding considerably more than $0.10 to their bill).
Slashdot Mirror
There was basically a choice to be made:
(a) Fix bugs in software that left processes unintentionally running past logout,
(b) Allow users to opt in to unconditionally killing processes on logout,
(c) Interactively ask users which process groups to keep, or
(d) BREAK ALL THE THINGS.
Only an idiot, an asshole, or an arsonist chooses (d), and I am inclined to think it's one of the latter two when they admit to knowing it will break things.
The other Unix slogan mentions re-implementing Unix, poorly. The systemd tools seem dead-set on living up to that one.
nohup is only one way to perform the steps that allowed a process to keep running after the user logged out. It isn't hard to do the same things within a program when and if it was necessary. systemd has broken programs that do that.
For example, take a daemon that has command-line switches to make it check its configuration files for obvious problems versus running in the background. With this systemd change, the only fine-grained way to make it work the way it was intended was to add a lot of command-line noise to places where it is started in its daemon mode. The global and per-user switches will leave buggy software still running when the user logs out.
People already did the work to keep their processes alive after their session leader exits. systemd is now breaking that work, apparently because GNOME's developers cannot figure out how to fix their own bugs, and must rely on systemd to clean up the cow droppings they leave all over the place.
A better person than you would be ashamed and admit their error and ignorance, rather than lamely accusing me of bad faith just because you can't answer the question.
The "alternative" mechanism you describe just isn't an alternative, it is orthogonal to the behavior under question. Again: Why is it okay to break the thing that has worked essentially as long as UNIX has existed just because an independent mechanism (for doing something entirely different) exists?
Why is it okay to break the 40+-year-old method for preserving a process after the login shell exits just because there is an orthogonal mechanism for applying resource quotas?
It is not "tightening up" security. There was already a little configuration step that made things work as desired. "nohup" was one way to do that, but processes could also do autonomously. Why do systemd tools keep wanting to break things that work?
Apparently you know nothing about the principle of least surprise.
What is more obvious, more common, and more widely understood: "nohup foo &" or "systemd --magic-grok --yes-i-want-this-to-stick-around --user --of-course-i-mean-user foo"? Which one has been the standard way to keep things running after a login shell exits for about 40 years?
If non-buggy software is running in its own process group, that's a pretty darn good indication to a competent sysadmin that it is meant to hang around.
That GNOME software is buggy should be news to nobody.
So you're saying systemd's functional delta could be easily replaced by a (at most) 500-line C wrapper that runs inside an init script?
I can understand wanting to apply resource quotas to some subset of processes. What I don't understand is tying that to a user's interactive session, much less using additional mechanisms to reproduce sessions/process groups, as systemd is doing in this case. It seems to me that you're defending using cgroups, which is only coincidentally related to systemd's behavior.
The standard says "If the process is a controlling process, the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process." No action required by that controlling process, or even discretion about it.
No, it is *not* self-evident that cgroups are an improvement for login sessions. For virtualization, sure, they make sense -- but I am unconvinced that the same kind of resource quotas make sense for login sessions.
"It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so."
No, it is not more complicated than what I said. A typical session leader does not kill the other processes in its session (or even process group). At some point -- say, because the login shell (which was the process group/session leader) exited -- the kernel sends SIGHUP to all the processes in the session, and the default handler for this terminates the processes in the session, and thus the session.
How is using cgroups an improvement over the POSIX way of doing things?
/. must have associated my comment with the wrong one of your spammy comments. I was responding to your assertion that now only "legitimate" processes will be running when you log out. Clearly, you don't have a clue about why that is *not* a pro-security approach.
You... might want to understand what you're criticizing before shooting off your mouth. Under POSIX, the login session lasts until the last process in it terminates, not until the login shell terminates.
So it's okay for malware to be running as long as you're logged in, but it has to stop when you log out?
That's the second stupidest thing I've read in this thread.
The fact that they documented their broken choices, and incorrectly label them "very conservative", does not change the fact that the changes are stupid and break well-considered, long-standing behaviors in order to clean up after other software that is equally stupid and broken.
Hello, electronic computers already made us bad at math. There used to be lots of people who made their livings by adding columns of numbers, doing multiplication and division and logarithms! Now those things are done by people only as curiosities, and basically nobody could make a living doing them. QED, or GED, or whatever.
It was actually meant as a mostly facetious example of why it isn't weird to use a comma in place of the word "and". I guess Americans' senses of humor are too subtle for modern Brits.
If he has gone regularly in the past, this incident will probably not change his habits, and if he doesn't go there regularly, him staying away won't be a big hit to their revenue. I'm wondering why he thinks the franchisee (or chain owner) should care enough either way to replace several workers with a manager.
Don't get me wrong: I would love it if competent managers were on duty at practically all customer-facing establishments. The flirting employees were wasting the customer's time and the employer's money. But I don't see the incentives lining up to fix the problem: In the places where the economics make sense, they probably do have decent managers on duty; in places where return traffic is infrequent or inelastic, and where cost is a large competitive factor, good managers will be less common.
That's a bigoted, misinformed complaint.
What would good management do in that case, except cost as much as two or three of those teenagers? The chain already has your money, so what are you going to do that impacts their bottom line?
Don't forget the repair techs. They'll probably be on H-1B visas, though, because the only BurgerFlip3000 repair certification program will be in Goa or someplace.
That $0.10/person extra works out to, what, $2/hour for the server? During relatively busy shifts? I don't think that's in line with minimum wage laws, even if the customers tip (adding considerably more than $0.10 to their bill).