I am issuing the following command to kill Firefox on my Red Hat Linux box:

[subhrcho@slc04lyo ~]$ pkill -9 -f firefox
[subhrcho@slc04lyo ~]$ 

However, when I try to invoke Firefox through Applications -> Internet -> Firefox, it says:

Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.

  • 2
    -9 isn't appropriate for most programs, use it for a shell only. With -9 a program can't do any cleanup. Try -15 instead.
    – ott--
    Mar 7, 2013 at 9:46
  • 1
    “Firefox is already running, but is not responding.” sounds like a good reason for involving SIGKILL.
    – manatwork
    Mar 7, 2013 at 9:52
  • 1
    In my experience, firefox takes some time before the "already running, not responding" gets cleared up.
    – vonbrand
    Mar 7, 2013 at 10:13
  • 1
    SIGKILL can't be handled by programs, so they can't perform any cleanup. In the case of Firefox this probably prevents it from getting rid of the profile lock. If you are just trying to terminate firefox normally, use SIGTERM.
    – njsg
    Mar 7, 2013 at 14:33
  • 1
    (Also, if you're not aware, signal 9 (-9) is SIGKILL, see man 7 signal.)
    – njsg
    Mar 7, 2013 at 14:33

5 Answers 5


Your firefox is already dead. You think it is still running because of a misleading error message (*). This is most likely a result of the previous kill -9.

Do not use kill -9 if not absolutely necessary. And most of the time it is not absolutely necessary.

This is what I think happened in your case:

  1. Firefox is running.
  2. You did pkill -9 -f firefox. Firefox is killed instantly (**). As such it did not had the chance to remove its lockfiles from the profile directory.
  3. You start a new firefox process.
  4. The new firefox process sees the lockfiles still in the profile directory and thinks that another firefox process is still running. It then refuses to start with the misleading error message.
  5. You are confused by the error message and think that firefox was not killed previously.
  6. You keep trying to kill firefox which has no effect because there is no firefox process running. At the same time you keep getting the same misleading error message because the lockfiles are still in place.

If you are sure that firefox is killed (check with pgrep -fl firefox) you can manually remove the lockfiles from the profile directory. For more information see this mozillazine article: http://kb.mozillazine.org/Profile_in_use.

(*) The error message is misleading because it says another process is running even though it does not actually check for another process. It just checks for the lockfiles. So the error message is just an indicator for the lockfile. Not necessarily for another process.

(**) Killed instantly as opposed to given the chance to clean up before terminating on its own terms. While killed instantly is the intended effect of kill -9 the consequences are often neither intended nor expected by the user.

Read on for more elaboration about this.

Background info:

Firefox maintains lockfiles in the profile directory. The lockfiles are there to prevent two instances of firefox accessing the same profile at the same time.

If you start firefox it will check for the lockfiles first. If there are no lockfiles then firefox will place it's own lockfiles and start normally. If there already are lockfiles then firefox will assume that this profile is used by another instance of firefox and show a misleading error message that there already is an instance running.

misleading because firefox only checks for the lockfiles. It does not check whether there are actual firefox processes running. Sometimes there are no other firefox instances running. Just the lockfiles left over.

If you close firefox normaly (mouse click on close button or alt+f4) it will not terminate immediately. Instead it will start a "shut down routine". That includes, among other, removing the lockfiles. If you observe the processes (for example using top) you will notice firefox not disappearing immediately from the process list.

If you kill firefox (without -9) it will not "kill" firefox. Instead it sends a signal. A signal named SIGTERM for terminate; commonly understood as the signal to "shut down now". Upon receiving the signal firefox will start the shut down routine as above.

If you press ctrl+c in a terminal (with firefox running from the same terminal) it will also send a signal. This time it is SIGINT for interrupt. This is semantically the same as SIGTERM for most end user programs. Firefox will start the shut down routine.

(side note: programs are not required to shutdown upon receiving these signals. some programs will do some specific work and then keep running. but this is not common in end user programs)

kill -9 is different. If you kill -9 firefox will not get a signal. It will not start the shut down routine. Instead it just ceases to exists. On the spot. Midstep. Anything left unwritten on disk will be lost. And, conversely, anything still on disk will stay on disk. The lockfiles will stay on disk.

Firefox, killed instantly with kill -9, had no chance to start the shut down routine and as such couldn't remove the lockfiles. Then, when you start firefox again, it will see the lockfiles and it will refuse to start with the misleading error message.

That is why you should not use kill -9 if not absolutely necessary, and most of the time it is not absolutely necessary.

For more discussion about why not kill -9 read this question and answer (and comments): When should I not kill -9 a process?.

For more info on signals: https://en.wikipedia.org/wiki/Signal_(IPC)

  • "You think firefox was not killed and you are confused". Okay, 99% likelihood you are right. In my decades of Unix experience I had never seen a process survive kill -9. Until today. Firefox is using up 100% of the CPU and kill -9 is not stopping it. I cannot attach to a debugger as that requires a signal as well, but I'm pretty sure it's a problem in the kernel (Linux 4.9.0). dmesg shows some "hung_task" messages about the zombie children (which did die), but nothing about the parent process. I'm flabbergasted.
    – hackerb9
    Sep 13, 2021 at 23:02

As far as I know, firefox creates a file called lockor something like that in ~/.mozilla/firefox/<your_profile>/ when it is executed. I don't know the exact behaviour, but sometimes it hinders you to run a second instance of firefox, or, if it is not deleted after closing firefox, to run a single instance at all. Try deleting this file, it should help.

  • 3
    If there is no firefox process running (which is likely the case, after all processes can't ignore SIGKILL), this is likely to be the cause of the error message.
    – njsg
    Mar 7, 2013 at 14:30

In my own experience, Firefox can sometimes take a minute (or even more) to finally shut down completely, as shown by system monitor. I don't know about Red Hat, but if you have system monitor, you might try using it to see if Firefox is still running, and if it is again from there give the kill command. That should do it.

  • 1
    I do realize the OP was not specifically asking for the information I provided in my answer but I was trying to help by emphasizing this fact about Firefox. I don't think it was really necessary to downvote my answer twice. Feb 11, 2018 at 5:45

I noticed this recently. You'll need to do pkill -9 GeckoMain. or pkill -f -9 firefox. If you look at /proc/<pid of a firefox>/comm, it doesn't say firefox.

Hope that helps


Try kill -9 `pidof firefox` and wait for a few seconds.

  • 1
    pidof firefox must be between backticks, they don't seem to appear for whatever reason.
    – schaiba
    Mar 7, 2013 at 9:46
  • 3
    Better use $() instead of backticks. (GreyCat's Why is $(...) preferred over ... (backticks)? article enumerates additional reasons.)
    – manatwork
    Mar 7, 2013 at 9:47
  • @schaiba I am seeing a "pidof: Command not found."
    – Geek
    Mar 7, 2013 at 9:48
  • Try @manatwork's solution, then.
    – schaiba
    Mar 7, 2013 at 9:54
  • @schaiba, if says “Command not found”, that sounds like the sysvinit-tools package (the one containing pidof on my system) is not installed there.
    – manatwork
    Mar 7, 2013 at 9:58

You must log in to answer this question.

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