Closed Bug 1427447 Opened 7 years ago Closed 6 years ago

Firefox Nightly almost always fails to update in the last several months

Categories

(Toolkit :: Application Update, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: nivtwig, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20171227100314 Steps to reproduce: Open Firefox Nightly. In the Help menu, click "About Nightly" . When Firefox Nightly is not updated, it will start a download of the update, and show a button with the label "Restart to update Nightly". Click it . Actual results: Nightly shuts down, but does not restart . Therefore I start it manually, but when it opens it is not updated. I click on Help ->"About Nightly" again to see the version, but it is still with the old version/date. Trying again and again to restart and update, does not help. This has been happening most of the times for the last several months. On rare occasions the update succeeded without problems. I didn't report it until now since I was convinced it is so apparent that someone else surely will report it, and it will be solved anyway. Expected results: Firefox should restart and update successfully.
Component: Untriaged → Application Update
Product: Firefox → Toolkit
I found a lock file firefox.exe.update_in_progress.lock from November (about one and a half months ago) in the Nightly directory. After deleting the file, it seems Nightly updated successfully. However, it seems that this happens from time to time, because I think I have this problem also on other computers, I will check those for the file when I have a chance. The question is: Isn't there a better way to handle the update process, so that this will not happen again (the creation of a leftover lock file), and prevent the next updates from successful completion?
I now had another problematic update: After the successful update of Nightly that was described in comment 1 , which did not leave a lock file after it, I had another update, so I clicked to restart and update Firefox in the "About Nightly" dialog box. (Before that I looked at the date-modified timestamp of firefox.exe and other files in the Nightly directory in order to know if they are actually updated) The browser shut down, Windows asked me to confirm the update (asked for administrator permission, I confirmed), but Nightly didn't restart as expected. Therefore I started Nightly manually. It seemed at first that it updated successfully, "About Nightly" stated that firefox is up to date, and the firefox.exe file and other files date-modified time was updated, although there are some files in the directory which didn't have "updated" dates. But I noticed that the firefox.exe.update_in_progress.lock lock file was again created in the directory, and wasn't removed even while firefox was running again after I started it so the update was supposed to be finished, but the lock file was still there. I assumed that there probably was a crash in shutdown that left the lock file there without deleting it, but about:crashes didn't show any new unsubmitted crash reports. Therefore I guess maybe there is no crash, but the update (or content?) process is killed by the main process or another process during shutdown before the update completes and the lock file deleted, and therefore the lock file is still there. Therefore it seems that the update process is broken and sometimes gets killed for some reason and leaves the lock file behind although the update process is no longer in progress, and this lock file is bad because it may prevent Nightly from updating in future updates.
Flags: needinfo?(robert.strong.bugs)
(In reply to nivtwig from comment #2) ... > Therefore I guess maybe there is no crash, but the update (or content?) > process is killed by the main process or another process during shutdown > before the update completes and the lock file deleted, and therefore the > lock file is still there. > > Therefore it seems that the update process is broken and sometimes gets > killed for some reason and leaves the lock file behind although the update > process is no longer in progress, and this lock file is bad because it may > prevent Nightly from updating in future updates. Maybe I had a mistake here: After that I tried to delete the lock file (after exiting Firefox, and making sure it is not longer running in task manager), but it wouldn't let me delete because the lock file is held by the "Firefox update process"(updater.exe). In task manager I saw 2 updater.exe processes, not one as expected, so I killed the first, but I couldn't kill the second from task manager. I couldn't also delete the lock file, because it was still held by the impossible-to-kill update process. I restarted my computer in order to get rid of the update process, and after that the lock file was gone or I deleted it manually (I don't remember exactly what happened, I think it was delete automatically) After that Firefox updated successfully. But the problem still remains - the Firefox update fails too many times due to leaving behind this lock file for some reason, and thus preventing future updates.
I now have another type of problem with updates, that is not related to a lock file: I open Help->"About Nightly", it starts a download of the update, which appears successful, but probably doesn't really download, or the download doesn't succeed : It starts the download of above 40MB size , but almost immdeiately appears to finish downloading which is not possible in such a short time (less than a second with a 30M bit, or 3MB/s, internet connection), and shows the button "Restart to update Nightly". When clicking the button to restart, Nightly just exits (verified in task manager) but doesn't restart automatically. Therefore I start it manually, and see from the date in "about Nightly", that Nightly wasn't updated. The "About Nightly" dialog tries again to download the update, the download seems successful, bug again and again it fails to update. In this type of problem with updates, there is no leftover lock file that prevents the update, as the lock file described in the previous comments .
(In reply to nivtwig from comment #4) > I now have another type of problem with updates, that is not related to a > lock file: I forgot to mention build id 20180129220114 , Windows 10 64-bit.

nivtwig,
Do you still see this when using a current version?

Flags: needinfo?(nivtwig)

I think that I had seen it several times since I filed it, but very rarely, therefore the bug can be closed.
If it happens again, I will report it in a separate bug.

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(nivtwig)
Resolution: --- → WORKSFORME
Flags: needinfo?(robert.strong.bugs)
You need to log in before you can comment on or make changes to this bug.