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
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):
Steps to Reproduce:
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 ***