umbrel
umbrel copied to clipboard
getumbrel
Add a '--all' flag to stop script for background processes
Description
This PR adds a --all flag to the scripts/stop script which looks for the background scripts that currently get kicked off in Umbrel and kills them with a -9 sigterm.
This option could be useful when doing dev and debug work on a manual install and shouldn't affect the other scripts that use the stop script internally.
Thanks for the PR, @vindard! This would indeed be very useful for development purposes.
In my testing, it seems to stop the background processes as intended, except one process (fswatch) which is spawned by karen:
root 1996 1 0 10:19 pts/0 00:00:00 fswatch -0 --event=PlatformSpecific /home/umbrel/vindard/events/signals
Also, if we're going this route, do you think it's a better idea to store pid for background processes in the start script (maybe in a new directory $UMBREL_ROOT/pids/) and then kill processes based off those pids?
Thanks for the PR, @vindard! This would indeed be very useful for development purposes.
In my testing, it seems to stop the background processes as intended, except one process (
fswatch) which is spawned bykaren:root 1996 1 0 10:19 pts/0 00:00:00 fswatch -0 --event=PlatformSpecific /home/umbrel/vindard/events/signalsAlso, if we're going this route, do you think it's a better idea to store
pidfor background processes in the start script (maybe in a new directory$UMBREL_ROOT/pids/) and then kill processes based off thosepids?
I think storing all pids can be useful for a convenient way of checking for stuff running
Also, if we're going this route, do you think it's a better idea to store pid for background processes in the start script (maybe in a new directory $UMBREL_ROOT/pids/) and then kill processes based off those pids?
Stopping the processes by tracking their PIDs instead of identifying by string match makes a lot of sense
I did some research and found a great way to do this by using the "process group ID" of the start script to be able to isolate and kill all child processes spawned (see here). With this method, we'd only need to store the PGID from the start script and then use that to kill all processes in the stop script. On my testing so far this seems to work well.
I'm currently persisting the PGID in a start_pgid.log file in the Umbrel root folder which gets deleted when the stop script is run with the --all flag.
I haven't tested this out yet but just a couple of observations:
Instead of the default behaviour leaving processes running and having an --all flag to kill them, it probably makes more sense for the default behaviour to kill everything and have a --preserve-update flag that prevents killing the update script.
When a user is stopping Umbrel, they will always want to stop everything. The only time we ever don't want to stop everything is during an OTA update when we want to stop Umbrel without killing the update script. And even then, we want to stop as much as possible, ideally also karen, just not the update job it just spawned. Then after OTA the user is running up to date background services.
I did some research and found a great way to do this by using the "process group ID" of the start script to be able to isolate and kill all child processes spawned (see here). With this method, we'd only need to store the PGID from the start script and then use that to kill all processes in the stop script. On my testing so far this seems to work well.
If the background services are already running, they won't be spawned again. So if you save the PGID of the latest start run, but that didn't spawn any background jobs because they were already running, I don't think killing based on the PGID would work.
In fact, come to think of it, maybe we don't need a flag at all.
We can just always kill all background processes.
We probably never want to kill karen triggers mid execution, so we can just implement something in karen that disowns its child processes.