I am trying to run a very complex statistical model that I expected to take a very long time, so I used nohup to run the process. However, I underestimated the length and it would take like 260+ days to complete so I want to cancel the process.

I attempted using ps aux |grep nohup to get the PID, I get the following output:

 \<username> 4920  0.0  0.0  14224   972 pts/15   S+   01:53   0:00 grep nohup

When I use kill -9 14224 I am told there is no process. So I used ps -ef | grep beast-2 as I do not remember the entire command I entered. Pulls up the following:

144039      1  0 Jul22 pts/12   00:00:00 /bin/sh /opt/anaconda3/bin/beast-2 -seed 777 -working -overwrite -instances 3 -threads 3 -beagle_SSE /home/<username>/XML/ST736_MTBD1.xml

I use kill -9 144039 and check again but the process is still running underneath a new PID.

What can I do?

2 Answers 2


Your process 14224 is the grep nohup, as ps told you. So, when you get your prompt back, the grep ended and therefore, it is logical that kill reports that there is no such process.

You will not see s process called nohup in your ps output.

So, how to find the process to kill?

As I don't have your beast-2, I will demonstrate with nohup sleep 99 &.

ps -ef | grep sleep

which would give me

ljm      1491988 1336776  0 16:43 pts/0    00:00:00 sleep 999
ljm      1492021 1492069  0 16:45 pts/0    00:00:00 grep sleep

1492021 is again my grep, so not important here. 1491988 is my nohupped sleep. The parent PID is 1336776. So checking it gives me

$ ps -f 1336776
ljm      1336776 1336769  0 Jul22 pts/0    Ss+    0:00 /bin/bash

That is a bash. You can go-up even further, , for example using pstree:

$ pstree -ap  1336769
      └─sleep,1492051 999

So, if you kill the parent, it will no longer spawn new beast-2s. Here I would

kill 1336769

which kills the console and the bash, but not the nohupped sleep:

$ ps -ef | grep sleep
ljm      1492051       1  0 16:48 ?        00:00:00 sleep 999
ljm      1492285 1492069  0 16:57 pts/1    00:00:00 grep sleep

The parent has now become 1, which is the init process. If you kill the sleep now,

$ kill 1492051
$ ps -ef | grep sleep
ljm      1492329 1492069  0 16:59 pts/1    00:00:00 grep sleep

then all is gone.

  • I think I understand. So then in my efforts I have accidentally killed the console and the bash after this post, so now there is nothing more I can do and now I have some computing resources that will always be used up until some Admin kills the process. Jul 23, 2021 at 15:05
  • @MicroBiostat Could you not just log in again as the same user? Kill does not depend on being in the same session as the runaway program. Jul 23, 2021 at 17:16
  • @Paul_Pedant You are correct, I was mistaken. Thanks Jul 24, 2021 at 13:57

In my case, I was protecting laravel using nohup. I had to also kill the process bound to the port

use fuser 8080/tcp (change the port based on your own) and kill the PID found there.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .