4 ms·

A lot of people (including me) learned about it the hard way when their tmux sessions began mysteriously disappearing. The solution is KillUserProcesses=no i

A lot of people (including me) learned about it the hard way when their tmux sessions began mysteriously disappearing. The solution is KillUserProcesses=no in /etc/systemd/logind.conf Some systemd advocates say the critics are just upset at change. I don't dislike change in general, but changing defaults out from under me? Defaults like this? That irks me. I lost a several tmux sessions before I realized what was happening. I thought I was doing something wrong because SystemD violated my expectations so severely.

loopz 7y ago
Turns out some people like to force change upon others. They will always win out. These same people are oblivious to cause and effect.
- deleted 7y ago
  [deleted]
yori 7y ago
Why did the sessions disappear? Can you explain more about it?
- fsh 7y ago
  Systemd can be configured to kill all processes belonging to a user when he or she closes the last login shell. Some people had this enabled on their servers and were surprised that their tmux/screen sessions kept disappearing.
  - seabird 7y ago
    This is a bit disingenuous; people didn't just "have it enabled", it was made a default despite a lot of concern that it was such a radical departure from the normal behavior.
  - fgonzag 7y ago
    Some people? Do you mean everyone who's distro did not change the default value?
api 7y ago
A system-wide setting when the objective is user process control behavior? Really? Just wow.
- kuschku 7y ago
  multi-user system, user logs out, do you want to have buggy software still hanging around? The whole point is for the administrators to be able to avoid users running long-running processes on shared systems (e.g. university systems).
  - JohnFen 7y ago
    > multi-user system, user logs out, do you want to have buggy software still hanging around? Of course not. But I do want to have the nohup software they have running to keep running when they log out. > The whole point is for the administrators to be able to avoid users running long-running processes on shared systems (e.g. university systems). Right, which is why it should be possible to do this. The issue is that the default behavior has changed from honoring nohup to not honoring nohup. Defaulting to honoring nohup is what's expected, and is reasonable.
ColanR 7y ago
I remember reading on HN at the time, how the systemD folks opened a bug report (or some such similar) on the tmux github because systemD was disappearing those tmux sessions, and their solution was for tmux to change how they managed persistency. Tmux stood their ground, and I think that's why KillUserProcesses=yes isn't still default. (iirc)

loopz 7y ago

Turns out some people like to force change upon others. They will always win out. These same people are oblivious to cause and effect.

deleted 7y ago
[deleted]

yori 7y ago

Why did the sessions disappear? Can you explain more about it?

fsh 7y ago
Systemd can be configured to kill all processes belonging to a user when he or she closes the last login shell. Some people had this enabled on their servers and were surprised that their tmux/screen sessions kept disappearing.
- seabird 7y ago
  This is a bit disingenuous; people didn't just "have it enabled", it was made a default despite a lot of concern that it was such a radical departure from the normal behavior.
- fgonzag 7y ago
  Some people? Do you mean everyone who's distro did not change the default value?

api 7y ago

A system-wide setting when the objective is user process control behavior? Really? Just wow.

kuschku 7y ago
multi-user system, user logs out, do you want to have buggy software still hanging around? The whole point is for the administrators to be able to avoid users running long-running processes on shared systems (e.g. university systems).
- JohnFen 7y ago
  > multi-user system, user logs out, do you want to have buggy software still hanging around? Of course not. But I do want to have the nohup software they have running to keep running when they log out. > The whole point is for the administrators to be able to avoid users running long-running processes on shared systems (e.g. university systems). Right, which is why it should be possible to do this. The issue is that the default behavior has changed from honoring nohup to not honoring nohup. Defaulting to honoring nohup is what's expected, and is reasonable.

ColanR 7y ago

I remember reading on HN at the time, how the systemD folks opened a bug report (or some such similar) on the tmux github because systemD was disappearing those tmux sessions, and their solution was for tmux to change how they managed persistency. Tmux stood their ground, and I think that's why KillUserProcesses=yes isn't still default. (iirc)