On Sun, 28 Aug 2022 13:25:45 -0700 Michael Ewan <michaelewa...@gmail.com> wrote:
> Kill -9 cannot be handled in the program, it kills > the program immediately leaving open files, memory allocations, swap space, > and all kinds of other stuff like child processes laying around. kill -9 aka SIGKILL is almost always a bad idea, but I just want to mention it does not leave open files, memory allocations, or memory mapped files like swap space. Those all get cleaned up completely. Files may be half written, but the file handles are closed. Child processes will still be laying around though, and those can have open files, memory allocations etc. > correct to use -15 (the default for kill pid). If that does not work then > kill -2 (quit with a core dump), or sometimes in the case of shells running > scripts you need kill -1 (better to use kill -HUP here so you do not > accidentally kill 1). /bin/kill -L or /bin/kill --table gives a nice summary of what numbers mean what: 1 HUP 2 INT 3 QUIT 4 ILL 5 TRAP 6 ABRT 7 BUS 8 FPE 9 KILL 10 USR1 11 SEGV 12 USR2 13 PIPE 14 ALRM 15 TERM 16 STKFLT 17 CHLD 18 CONT 19 STOP 20 TSTP 21 TTIN 22 TTOU 23 URG 24 XCPU 25 XFSZ 26 VTALRM 27 PROF 28 WINCH 29 POLL 30 PWR 31 SYS I usually start with gdb like # gdb -p $offending_process_pid to try to see what's going wrong, get a backtrace maybe. Then I use CONT (just in case) and like you said TERM, INT, QUIT and finally HUP. If it doesn't die after that, I throw various signals at it like PIPE, ILL and BUS, and SEGV. Then I use KILL. Then I go online to find out how the holy heck a process could ignore a SIGKILL, and discover that valgrind's vgdb does something magical to make its traced process entirely immune to signals. But hopefully it doesn't get to that point.
