You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 4, 2023. It is now read-only.
One of the key motivations of poorman: Ensure managed processes actually die on exit.
Occasionally processes need a kill -9. It's a frustrating experience for developers to have to chase down rogue processes, especially during development and integration testing when things may not be stable. However, poorman itself should exit as soon as possible and there's no way to know whether a process is cleaning up after itself or is stuck indefinitely.
After the 1.0 release (#3), poorman can deviate from foreman by adding a poorman kill [KILL ARGS] command which calls the kill command with the kill args. Arguments are optional after poorman kill,
Once implemented:
Document the kill subcommand in the README.
Add this to the README on differences between poorman and foreman.
Add a note to use poorman kill; true, as poorman gives feedback in its status code.
Add a note to the usage section in the README to ignore .poorman-kill, which is the script that poorman will write to implement this feature.
For usage, poorman kill could either log IDs of processes being killed or run in set -x mode, and write to stderr when there are no processes to kill and exit 1. The poorman kill command should clean up the .poorman-kill file upon exit.
poorman could set itself up in the "not totally naive" way by querying for which processes are still running, and only set itself up to kill those on the next invocation. The goal here would be to "do nothing" for commands which behave well and exit immediately.
This approach will give full control to the developer, without having an opinion about how long processes should take to exit, while seeking an exit from poorman's main process as soon as possible (as kill 0 is the most complete approach to killing the process group), and assumes that not all processes are broken.
The text was updated successfully, but these errors were encountered:
On further thought, the poorman kill exit code can be 0 when there's nothing to kill, but it was called correctly. Exit code 2 would mean .poorman-kill does not exist. To find the number of processes killed, count the lines of output (meaning that the implementation must keep to one line of stdout on each kill invocation).
It probably makes sense for both poorman and poorman kill to check if the process exists before invoking kill (since .poorman-kill will only be called from poorman itself, it can export function definitions), as to provide accurate information and expose as little as possible to the developer.
An alternative approach would be a polling loop which checks each PID to see that the process stopped, then take another interrupt from the user to send a SIGKILL.
docker-composedoes this, Gracefully stopping... (press Ctrl+C again to force).
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
One of the key motivations of poorman: Ensure managed processes actually die on exit.
Occasionally processes need a
kill -9
. It's a frustrating experience for developers to have to chase down rogue processes, especially during development and integration testing when things may not be stable. However, poorman itself should exit as soon as possible and there's no way to know whether a process is cleaning up after itself or is stuck indefinitely.After the 1.0 release (#3), poorman can deviate from foreman by adding a
poorman kill [KILL ARGS]
command which calls thekill
command with the kill args. Arguments are optional afterpoorman kill
,Once implemented:
poorman kill; true
, as poorman gives feedback in its status code..poorman-kill
, which is the script that poorman will write to implement this feature.For usage,
poorman kill
could either log IDs of processes being killed or run inset -x
mode, and write to stderr when there are no processes to kill and exit 1. Thepoorman kill
command should clean up the.poorman-kill
file upon exit.poorman could set itself up in the "not totally naive" way by querying for which processes are still running, and only set itself up to kill those on the next invocation. The goal here would be to "do nothing" for commands which behave well and exit immediately.
This approach will give full control to the developer, without having an opinion about how long processes should take to exit, while seeking an exit from poorman's main process as soon as possible (as
kill 0
is the most complete approach to killing the process group), and assumes that not all processes are broken.The text was updated successfully, but these errors were encountered: