On Mon, May 30, 2016 at 7:12 AM, Paul Wouters <paul(a)nohats.ca> wrote:
On Sun, 29 May 2016, Chris Murphy wrote:
> On Fri, May 27, 2016 at 5:03 PM, Paul Wouters <paul(a)nohats.ca> wrote:
>> If there is a systematic
>> problem of badly written code leaving orphaned code running when
>> a user logs out, then that broken code should be fixed instead of
>> adding another layer of process management. systemd is not capable
>> of interpreting the user's intent.
> That isn't working. Users are constantly running into restart and
> shutdown delays. Troubleshooting this to find out what process is
> holding things up is totally non-obvious. Identifying the process is
> half the problem, and then getting it fixed and released to Fedora can
> be months, by which time some other process is affected.
Taking a shotgun isn't going to help that. Actually, if "bad code
upstream" is the problem, you can just wait on all of that code
starting to tell systemd they want to linger to avoid getting shot
by systemd for doing something wrong.
The metaphor is vaguely entertaining, but it's not like the shotgun is
the first or second action in the sequence. It's only once the first
two fail that the shotgun method is invoked, which by the way happens
anyway on restart and shutdown 1m30s later.
I think there's a distinction between incidentally bad code causing
these logout and restart delays, where code starting to request linger
when this isn't strictly necessary is intentional subterfuge.
So this whole thing becomes another abstraction layer that serves no
purpose, and just causes collateral damage.
For restart and shutdown it seems uncontroversial behavior to obtain
escalated action requested by the user. The gray area might be
strictly with logouts. So is there a way to carve out the more
aggressive clean up of user processes only at restart/shutdown time,
while leaving less aggressive clean ups when merely logging out?