On Wed, Jun 08, 2016 at 12:13:48PM +0200, Didier Kryn wrote:

[cut]

>

>     Yes, nohup. I guess it issues setsid() and disconnects from the
> controlling terminal, but any process can do that on its own. I was thinking
> of a way to decide which session can do that and which cannot, and I imagine
> it is only possible by running the session in a container (I don't know in
> detail how containers work), which is AFAIU what systemd does, but might be
> done by KISS means.

>

[sorry for the long reply]

I don't objct that having the possibility to *choose* which process
survives a session and which does not is a nice feature, which anyway
has been available in unix systems for the best part of the last 35
years.

The main problem with the "solution" proposed by systemd is that it
breaks things that already work (e.g., screen, nohup, mosh, and
thousands of user programs, for which this "behaviour" is totally
unexpected and meningless...) by enforcing an entirely new *policy*,
motivated by the availability of a convoluted *mechanism*, which in
turn was invented to solve the problems of poor programming of
GNOME-related programs that remain hanging out there for who knows
what reason.

Now, I know that this is the normal practice in other OS environments,
but in unix it is customary to not break existing things just to fix
the problems of poor programming practices and wrong architectural
choices. We can't and we shouldn't enforce a policy to justify the
adoption of a mechanism, because this is turning the world upside
down, for absolutely no reason.

Mechanisms are just "tools which allow you to do things". Policies are
the combination of appropriate mechanisms put together in such a way
to accomplish a certain task in a certain way, according to the
*needs* and *choices* of the user/admin. Mechanisms are (or should be)
policy-neutral, because policies are the result of user's *choice*,
and the mechanism cannot make such choice on behalf of the user, first
and foremost because there is no such thing as "the typical user", at
least not in a unix environment. And for sure not in a "Universal
operating system".

Killing all the processes at logout should be easily doable using
cgroups (which existed much before Poettering got his bachelor
degree), and is indeed easily doable with screen, nohup, and hundred
of similar amenities. Those *mechanisms* exist already, and new ones
can and should be introduced as needed, to complement the existing
ones, so that they can be combined in thousands of different new ways,
to serve the needs of different and emerging use cases. But it is not
possible to enforce the policy "all the processes that want to survive
have to use a precise mechanism", which in the meanwhile breaks
backward compatibility with other mechanisms and other policies. This
is not innovation. This is just breaking things for the sake of it.

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]