Red Hat Bugzilla – Bug 435479
Firefox is prevented from starting by a lockfile after a system or firefox crash
Last modified: 2008-09-26 14:27:40 EDT
+++ This bug was initially created as a clone of Bug #162462 +++ Description of problem: When the OS or firefox crashes firefox leaves a lock file that prevents firefox from starting. This is an annoyance for me as it happens a couple of times a week; however for a 'normal' computer user it is unacceptable. To expect a normal computer user to have the ability to delete a hidden file on a random path before they can use a web browser is unacceptable. Version-Release number of selected component (if applicable): firefox-2.0.0.12-1.fc8 How reproducible: Always Steps to Reproduce: 1.Open Firefox 2.Crash the OS either deliberately or wait for it to happen 3.Reboot and try to start Firefox Actual Results: Firefox fails to start Expected Results: Firefox should start when requested, perhaps prompting to remove lock files. The "lock" symbolic link should be recognized as stale because it points to a non-existant process. The IP address can be matched to see if it is local. If it is and the process doesn't exist it should be considered safe to remove it and .parentlock (what's that about?).
If this issue turns out to still be reproduceable in the latest updates for this Fedora Core release, please file a bug report in the the upstream bugzilla located at http://bugzilla.mozilla.org in the particular component. Once you've filed your bug report to the upstream bugzilla, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates. Setting status to NEEDINFO, and awaiting upstream bug report URL for tracking. Thanks in advance.
This seems like the best match. No progress in 2 years. Yeesh.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.
*** This bug has been marked as a duplicate of bug 435480 ***