On 06/01/2016 09:48 AM, Lennart
As presently designed, it's a usability problem because it collides
with the often-required idle session timeout. Your desktop session
will stay up, but any remote connections subject to idle timeout
will kill long-running jobs on logout. Since in general we can't
predict how long the command will take (especially the system
administration commands), we will have to use the convoluted
invocation to persist the jobs across the unpredictable idle logout,
or disable the feature.
On Wed, 01.06.16 12:19, Howard Chu (email@example.com) wrote:
This is still looking at the problem back-asswards. The problem isn't that
screen and tmux are special cases. The problem is that some handful of
programs that got spawned in a GUI desktop environment are special cases,
not exiting when they should.
Fix the broken programs, don't force every well-behaved program in the
universe to change to accommodate your broken GUI environment. This is
Again, this isn't just work-arounds around broken programs. It's a
security thing. It's privileged code (logind, PID 1) that enforces a
clear life-cycle on unprivileged programs.
Any scheme that relies on unprivileged programs "being nice" doesn't
fix the inherent security problem: after logout a user should not be
able consume further runtime resources on the system, regardless if he
does that because of a bug or on purpose.
It's ironic because as you point out it's a security risk to leave
those processes running, and yet the sensitive systems are more
likely to have the idle timeout turned on.