On 05/27/2016 01:54 PM, Chris Murphy wrote:
It seems to  me systemd should be able to know the difference between
a program that's zombie or unresponsive but isn't doing anything or is
unresponsive but is doing something; and if not then some way for
programs to say "hey wait just a minute, I need to clean things up" or
whatever, rather than just abruptly killing them.
I think our technical debt is catching up with us, because there's no consistent way to treat some processes as persistent, and others as disposable: we just did this type of process management by hand. Solving this systematically may be tricky because there's many different scenarios. Processes can be:

- totally disposable across logins, shouldn't even be relaunched on logging back

- disposable across login, but should reappear, e.g. the calendar on the desktop

- should keep running, e.g. the battery tester collecting the battery discharge data I am running now

- should keep running and restart if killed/crashed/rebooted: e.g. a weather/thermostat monitoring app

Systemd at least offers facilities to manage processes that, I think, allows for all those use cases. The difficulty is that systemd is fairly complex, and it would be nice if those use cases were easily available to a desktop user who may not be intimately familiar with writing systemd unit descriptions. I don't even know what would be an appropriate workflow for dealing with this: a rightclick GUI option? a commandline wrapper that runs the process as a service? Maybe some annointed processes like tmux/screen should automatically be exempt from termination? How about shell background processes: should an explicit & mean that the process keeps running across logouts?