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?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
