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 ] _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
