On 06/01/2016 09:48 AM, Lennart Poettering wrote:

On Wed, 01.06.16 12:19, Howard Chu (hyc@symas.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
Programming 101.

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.

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.

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.