SIGKILL isn't killing the child? about cargo-watch HOT 3 CLOSED

Anyway, thank you for the explanation, I suppose there's nothing to complain about here :) One day unix knowledge will stop dropping out of my head as easily as a sigkilled process

from cargo-watch.

In unix, SIGKILLing a process that has a child generally leaves an orphan around, yes. That's because KILL is immediate and cargo-watch can't do cleanup, like terminating child processes and wait()ing them. SIGTERM is usually the way to go when killing processes, with KILL as fallback, as the parent can catch that and cleanup.

For your immediate problem, consider using screen/tmux/zellij?

from cargo-watch.

I'm using VS Code remote, sometimes I close my laptop and the connection dies and ... not sure what's supposed to happen to the processes, but the watch is gone and the child stays around. Understood about the SIGKILL (actually I'm not sure that's exactly what Code sends on session timeout), I guess I have to find some kind of a hack, maybe something that will check that the parent is alive inside my process

from cargo-watch.