On Mon, May 30, 2016 at 7:12 AM, Paul Wouters <paul@xxxxxxxxx> wrote: > On Sun, 29 May 2016, Chris Murphy wrote: > >> On Fri, May 27, 2016 at 5:03 PM, Paul Wouters <paul@xxxxxxxxx> 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? -- Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
