6

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.

Ricardo Altamirano
  • 829
Geek
  • 6,688
  • 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 07 '13 at 09:46
  • 1
    “Firefox is already running, but is not responding.” sounds like a good reason for involving SIGKILL. – manatwork Mar 07 '13 at 09:52
  • 1
    In my experience, firefox takes some time before the "already running, not responding" gets cleared up. – vonbrand Mar 07 '13 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 07 '13 at 14:33
  • 1
    (Also, if you're not aware, signal 9 (-9) is SIGKILL, see man 7 signal.) – njsg Mar 07 '13 at 14:33

5 Answers5

11

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)

Lesmana
  • 27,439
  • "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 '21 at 23:02
6

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.

GriffinPeterson
  • 93
  • 6
  • 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 07 '13 at 14:30
0

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.

Obiwan Kenoobi
  • 25
  • 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. – Obiwan Kenoobi Feb 11 '18 at 05:45
0

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

placid chat
  • 711
-4

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

manatwork
  • 31,277
schaiba
  • 7,631