Kill a process that keeps restarting

Question

What if 'kill -9' does not work? or How to kill a script which starts new processes? doesn't help me in anyway.

I have a python script which starts automatically with another process id using the same port when killed using sudo kill -9 <pid>.

$ lsof -i :3002
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
python  13242 ubuntu    3u  IPv4  64592      0t0  TCP localhost:3002 (LISTEN)
$ sudo kill -9 13242
$ lsof -i :3002
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
python  16106 ubuntu    3u  IPv4  74792      0t0  TCP localhost:3002 (LISTEN)
$ sudo kill 16106
$ lsof -i :3002
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
python  16294 ubuntu    3u  IPv4  75677      0t0  TCP localhost:3002 (LISTEN)

It's not a Zombie process.

$ ps -Al

4 S     0 16289     1  0  80   0 - 12901 poll_s ?        00:00:00 sudo
4 S  1000 16293 16289  0  80   0 -  1100 wait   ?        00:00:00 sh
0 S  1000 16294 16293  0  80   0 - 34632 poll_s ?        00:00:00 python

I have even tried sudo pkill -f <processname> with no luck. It doesn't want to die.

Update:

It's parent process is sh whose parent is sudo as mentioned in the above table. I am not sure if it is safe to kill these abruptly. Also this is a shared ubuntu server.

Solution 1

Starts automatically with another process ID means that it is a different process. Thus there is a parent process, which monitors its children, and if one dies, it gets respawned by the parent. If you want to stop the service completely, find out how to stop the parent process. Killing it with SIGKILL is of course one of the options, but probably not The Right One^TM, since the service monitor might need to do some cleanup to shut down properly.

To find the monitor process, you might need to inspect the whole process list, since the actual listeners might dissociate themselves from their parent (usually by the fork() + setsid() combo). In this case, I find the output of ps faux (from procps at least, might vary for other implementations) rather handy - it lists all processes in a hierarchical tree. Unless there has been a PID wrap (see also wikipedia), the monitor PID should be smaller than PID of any of the listeners (unless of course you hit a PID-wraparound).

Solution 2

If you know the listening port of the process, you can use fuser with -k flag.

Something like,

fuser -k 3002/tcp

Comments

[Lakshminarayanan Guptha]

Yes it doesn't want to die forever. Wakes up like it never died :(

[Lakshminarayanan Guptha]

Its parent is sh whose parent is sudo. Is it ok to kill them?

[peterph]

Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linux procps, I usually find the output of ps -faux to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).

[Lakshminarayanan Guptha]

Great. ps -faux helped to start killing from the parent. Can you please update your answer with the solution from the comment?

[peterph]

Yes, I was thinking about it... :)

[gorodezkiy]

ps faux helped to detect supervisord which endlessly restarted hanged up Laravel queue daemon