440526 - FireFox will not restart after system crash

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Seven]

User-Agent:       Opera/9.50 (X11; Linux i686; U; en)
Build Identifier: Mozilla Firefox 3.0b5

I installed Mozilla Firefox 3.0b5 yesterday onto a RedHat/Fedora Core 9 (64 bit running a 32bit install).  Everything seemed to go fine in the install yesterday and all this morning.  There was at least one FF window open when the following happened.

The machine "hung" a little while ago -- I am not suggesting at this point that FF caused the hang.  I had to power cycle the machine to get it to reboot.  After the reboot I tried to restart Firefox but get a popup message that 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.

FireFox is not running according to 'ps'.  I am assuming that there must be a lock file that is still hanging around but I can not find it and the man page does not list it.

Reproducible: Always

Steps to Reproduce:
1.Assuming that you had a working, open FF session before a machine crash... crash the system
2. reboot
3. try to restart FF
Actual Results:  
a pop-up widow with the message 

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.

Expected Results:  
Actually start a new FF session

Comment 1

[Matthias Versen [:Matti]]

Please read http://kb.mozillazine.org/Profile_in_use

Comment 2

[Seven]

Thanks Matti.  That is exactly what I needed but could not find.

All the best,

Comment 3

[Jason Mansour]

I would not call this resolved... I too have this problem sometimes, and have to delete the ".parentlock" and "lock" files from my profile folder to run firefox again.

In this case, the error message is wrong and confusing. Rebooting doesn't help. A casual user would either reinstall Firefox, or give up at this point. (I know this from experience.)

IMHO, this should not happen at all. Using lock files to determine if an application is running isn't a very good practice...

Comment 4

[Seven]

This profile locking business should be re-examined in full.  If you *must* locak a profile then please let it be per machine or session not per profile.  Example, in our environment I have a "home" directory on central-machine-X.  When I login to desktop-M my home dir is "mounted" on this new machine.  If I have two machines in my office and login to both then my home dir is on both.

I can start FF on the first machine but then the second machine claims the FF is running.

Comment 5

[Matthias Versen [:Matti]]

>This profile locking business should be re-examined in full
THe whole profile history is 10 years old and fully examined.

>If you *must* locak a profile then please let it be per machine or session not per profile. 

You don't seem to understand why we do this at all. 2 independent processes writing to the same profile will corrupt the profile. It doesn't matter if the 2 processes are running on the same system or not.

>I can start FF on the first machine but then the second machine claims the FF
>is running.

You can create an additional second profile as workaround.

But this bug is not about the sharing of the profile, that is another bug which is ~6+ years old and still open.