On Tue, Jul 12, 2016 at 02:34:04PM -0400, Przemek Klosowski wrote:
> On 07/12/2016 06:15 AM, Lennart Poettering wrote:
> >That's hardly useful, as "screen" alone is useless as it's just a
> >frontend to other programs (such as a shell that is run inside the
> >"screen" instance), and if we kill those, then "screen" doesn't need
> >to be around either...
> Right---the entire process trees were started by the user for some
> specific purpose, and this mechanism can't just arbitrarily kill
> parts of that tree, so, as you point out, the children of the
> 'whitelisted' processes would would have to inherit the immunity.
>
> This shows why it's a difficult problem and also that we may be
> trying to discuss and solve it on the wrong level. The goal is to
> kill processes that have no business persisting, while leaving the
> useful ones---but how do we determine what should persist? We're
> trying to do some heuristics here, and I am not sure if they can be
> good enough.
>
> Perhaps we should be looking at a different level, seeing the
> situation in terms of a desired function/objective rather than
> looking at individual processes; or having a different activation
> sequence ('run normally/ephemerally' vs 'run persistently'); or
> looking at the process behavior (kill everything that sits in
> select()). Then again, the behavior should depend on the device:
> different on a handheld, desktop and server.
I have the feeling that by this the discussion has gone the full
circle: after all setting K.U.P=yes and requiring an explicit systemd
scope to stay around is a way to state the intent of being a permanent
process. An explicit request is a more robust way than any heuristics.
A big implementation detail is whether screen/tmux/etc should
do it themselves. In principle this isn't required, and those
programs can e.g. be invoked using systemd-run explicitly.
Nevertheless, I think that from the usability perspective it
is much better if such programs do this on their own.
Of course from the systemd side we should provide a simple and easy
mechanism that can be used with minimal fuss. That is my intent, and
I think that the knee-jerk reaction on the tmux bugtracker was
completely premature. If we have such functionality in screen/tmux/etc,
expressing the intent should be a matter of simple switch.
A lot of people seem to think that some mechanism to state such
intent would be OK. We probably cannot make it fully automatic,
but we should be able cover most cases where people want to things
to stay around after logout. There always will be other cases which
would require changes to how people call some programs, but hopefully
the advantages in the common case will outweigh this disruption.
Zbyszek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
