|
On 05/27/2016 01:54 PM, Chris Murphy
wrote:
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: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. - 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@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
