Not bad, but one big criticism, never do a 'kill -9' first, that will stop the program from cleaning up after itself if killed using -9.

Use one of these instead:

    -TERM   then wait, if not
    -INT    then wait, if not
    -HUP    then wait, if not
    -ABRT

If you are sure all of these fail, then use -9 (-KILL). But assume the program has a major bug and try and find another program that will do the same task and use that instead.

▲ adrianmonk 2 hours ago | parent | next [-]

Maybe this logic should be built into the "kill" command (or some other standard command). Given that this is the right way, it shouldn't be more tedious than the wrong way!

It could also monitor the target process and inform you immediately when it exits, saving you the trouble of using "ps" to confirm that the target is actually gone.

▲ BenjiWiebe 2 hours ago | parent | prev | next [-]

How often does plain 'kill <pid>' not work, but some other signal other than SIGKILL works?

Usually the process is either working correctly and terminates when asked, or else not working correctly and needs to be KILLed.

	▲	consp 27 minutes ago \| parent [-]
		Lots of commandline tools will hold on to dear life except for the sigkill. I often have this with running background tasks which get one of their threads in an infinite loop or wait state.

▲ consp 29 minutes ago | parent | prev [-]

This is article is likely LLM generated and it regurgitates as first go what the last resort should be. After seeing that command I stopped reading.