Closed
Bug 760027
Opened 12 years ago
Closed 12 years ago
Software update failed with "The update could not be installed. Please make sure there are no other copies of Firefox running on your computer..."
Categories
(Toolkit :: Application Update, defect)
Tracking
()
RESOLVED
FIXED
mozilla15
People
(Reporter: jaws, Assigned: ehsan.akhgari)
References
Details
Attachments
(4 files, 3 obsolete files)
"The update could not be installed. Please make sure there are no other copies of Firefox running on your computer, and then restart Firefox to try again." This has happened to me twice since bug 307181 landed. I get this when going to the About dialog and clicking on the "Restart to update" button. This only appears to happen after a long browsing session, where Firefox is slow to shut down. I'll see if I can find the relevant logs to attach here.
Reporter | ||
Comment 1•12 years ago
|
||
Date modified: 5/31/2012 2:47am
Reporter | ||
Comment 2•12 years ago
|
||
Date modified: 5/31/2012 2:47am
Reporter | ||
Comment 3•12 years ago
|
||
Date modified: 5/31/2012 2:40am There are 7 more logs but the rest of them have date-modifieds of 5/30 and earlier. I can attach those too if they will help in diagnosing this.
Reporter | ||
Updated•12 years ago
|
Attachment #628644 -
Attachment mime type: text/x-log → text/plain
Reporter | ||
Updated•12 years ago
|
Attachment #628645 -
Attachment mime type: text/x-log → text/plain
Reporter | ||
Updated•12 years ago
|
Attachment #628647 -
Attachment mime type: text/x-log → text/plain
Comment 4•12 years ago
|
||
Thanks Jared, Ehsan it sounds like in maintenanceservice-2.log maybe the replace stage of the background updates is not waiting for firefox.exe to be shut down.
Comment 5•12 years ago
|
||
Maybe adding a sleep at shutdown after the command is executed but before firefox.exe exits would help reproduce the problem consistently.
Comment 6•12 years ago
|
||
actually from that log, I think that's a log from the apply stage, so I don't know what the problem is there.
Assignee | ||
Comment 7•12 years ago
|
||
No, the log #2 is from the replace stage given the command line, and the fact that the updater is copied to the temp directory... Something else which is puzzling is the other two logs. Is there a case where this should happen with the service?
Assignee | ||
Comment 8•12 years ago
|
||
Jared, can you please zip up your C:\Users\username\AppData\Local\Mozilla\Firefox directory and attach it here? Also, once you've done that, can you see if you can reproduce this by downloading an older nightly and trying to update again?
Comment 9•12 years ago
|
||
I suspect the other 2 logs are a different bug where not all args are passed in, probably somewhere after error code 7 happens.
Assignee | ||
Comment 10•12 years ago
|
||
(In reply to Brian R. Bondy [:bbondy] from comment #9) > I suspect the other 2 logs are a different bug where not all args are passed > in, probably somewhere after error code 7 happens. Hmm, that should not be happening at all... That could be from the staging pass for example. Let me read the code a bit... Jared, if you can reproduce this in the future, could you see if you have this directory: C:\Program Files (x86)\Nightly\updated, and if you do, could you list its contents please?
Comment 11•12 years ago
|
||
It'll only happen when you have 2 or less command line args sent to the service. Windows includes 2 on its own so that means there are 0 args sent to the service. You can get this exact error if you manually try to start Mozilla Maintenance Service from Administrative tools -> Services. Maybe that's what Jared did for those 2 error logs?
Comment 12•12 years ago
|
||
I've been receiving the message "The update could not be installed...." for the past week on Windows XP. I've only been able to update by new images from http://nightly.mozilla.org/ . Would information would be useful to debug this issue? I can't find any maintenanceservice.log file on my system using Windows file search.
Comment 13•12 years ago
|
||
There's definitely something new going on here, but we've always gotten some error code 7's by the way. This will also happen when people have 2 profiles running and try to do an update. Telemetry data before bgupdates landed: error code 7: 1.8% Telemetry data after bgupdates landed: error code 7: 4.11%
Comment 14•12 years ago
|
||
Disabled unneeded token privilege: SeAssignPrimaryTokenPrivilege. Disabled unneeded token privilege: SeAuditPrivilege. Disabled unneeded token privilege: SeBackupPrivilege. Disabled unneeded token privilege: SeCreateGlobalPrivilege. Disabled unneeded token privilege: SeCreatePagefilePrivilege. Disabled unneeded token privilege: SeCreatePermanentPrivilege. Disabled unneeded token privilege: SeCreateSymbolicLinkPrivilege. Could not disable token privilege value: SeCreateTokenPrivilege. (1300) Disabled unneeded token privilege: SeDebugPrivilege. Could not disable token privilege value: SeEnableDelegationPrivilege. (1300) Disabled unneeded token privilege: SeImpersonatePrivilege. Disabled unneeded token privilege: SeIncreaseBasePriorityPrivilege. Disabled unneeded token privilege: SeIncreaseQuotaPrivilege. Disabled unneeded token privilege: SeIncreaseWorkingSetPrivilege. Disabled unneeded token privilege: SeLoadDriverPrivilege. Disabled unneeded token privilege: SeLockMemoryPrivilege. Could not disable token privilege value: SeMachineAccountPrivilege. (1300) Disabled unneeded token privilege: SeManageVolumePrivilege. Disabled unneeded token privilege: SeProfileSingleProcessPrivilege. Could not disable token privilege value: SeRelabelPrivilege. (1300) Could not disable token privilege value: SeRemoteShutdownPrivilege. (1300) Disabled unneeded token privilege: SeRestorePrivilege. Disabled unneeded token privilege: SeSecurityPrivilege. Disabled unneeded token privilege: SeShutdownPrivilege. Could not disable token privilege value: SeSyncAgentPrivilege. (1300) Disabled unneeded token privilege: SeSystemEnvironmentPrivilege. Disabled unneeded token privilege: SeSystemProfilePrivilege. Disabled unneeded token privilege: SeSystemtimePrivilege. Disabled unneeded token privilege: SeTakeOwnershipPrivilege. Disabled unneeded token privilege: SeTcbPrivilege. Disabled unneeded token privilege: SeTimeZonePrivilege. Could not disable token privilege value: SeTrustedCredManAccessPrivilege. (1300) Disabled unneeded token privilege: SeUndockPrivilege. Could not disable token privilege value: SeUnsolicitedInputPrivilege. (1313) Executing service command clear-prefetch, ID: ea51fc5e-1102-490b-8e1c-4e3574ead130 Service command not recognized: clear-prefetch. service command MozillaMaintenance complete with result: Failure. This is the issue i have trying to update from the 28th may build :(
Comment 15•12 years ago
|
||
CruNcher: You would need to attach a zip of all logs, those logs can be safely ignored. Anything with "Service command not recognized: clear-prefetch." is just using an old service but having the prefetch task and is known to be ok and safe.
Comment 16•12 years ago
|
||
i think i might have found whats going on a 3rd party didn't closed a handle when executing firefox.exe but this never caused problems with the old update system now it seems much more picky ill try to find all handles and see if that fixes this though i must say the old update system was much more robust :(
Assignee | ||
Comment 17•12 years ago
|
||
(In reply to CruNcher from comment #16) > i think i might have found whats going on a 3rd party didn't closed a > handle when executing firefox.exe but this never caused problems with the > old update system now it seems much more picky ill try to find all handles > and see if that fixes this though i must say the old update system was much > more robust :( Which third party application are you using?
Comment 18•12 years ago
|
||
I was reporting a bug for another Software Nexus Mod Manager http://skyrim.nexusmods.com/content/modmanager/ and i did this by using the in Application Help Menu which links to their Bug forum and Firefox was executed from there, now i closed the Application the handle to the firefox folder was freed and the update of Firefox worked and i have to write another bug report ;) Thx Brian, though such things wouldn't have happened with the old update so as i said everyone has now to be triple more careful :)
Comment 19•12 years ago
|
||
I talked to Jared on IRC... The first logs were confirmed to be from restarting the service manually. So those can be safely ignored. Jared also mentioned that he doesn't think he had a folder open nor third party softwrae that would have caused error code 7. I still think this may be a duplicate of Bug 757907 though and adding better handling there may fix this.
Comment 20•12 years ago
|
||
Btw i wasn't really aware anymore that i started Firefox this way as i was using it afterwards heavily. I guess many more applications will just leave the handle open @ their entire runtime until closed and as long this is the case Firefox can't be anymore updated currently :( I guess your telemetry data might be skyrocketing soon ;)
Assignee | ||
Comment 21•12 years ago
|
||
(In reply to CruNcher from comment #18) > I was reporting a bug for another Software Nexus Mod Manager > http://skyrim.nexusmods.com/content/modmanager/ and i did this by using the > in Application Help Menu which links to their Bug forum and Firefox was > executed from there, now i closed the Application the handle to the firefox > folder was freed and the update of Firefox worked and i have to write > another bug report ;) > Thx Brian, though such things wouldn't have happened with the old update so > as i said everyone has now to be triple more careful :) This should be improved with bug 757965.
Reporter | ||
Comment 22•12 years ago
|
||
Brian, the steps that you describe in bug 757907 describe exactly what was happening for me (with the exception of the cmd prompt open to the Nightly directory).
Comment 23•12 years ago
|
||
Jared could you attach these files: C:\Users\<username>\AppData\Local\Mozilla\Firefox\Nightly\updates last-update.log backup-update.log Thanks!
Reporter | ||
Comment 24•12 years ago
|
||
I checked in my Nightly\updates folder and the two log files there both showed no mention of errors (they had been overwritten with newer logs). If I run in to the issue again I'll attach those logs here.
Reporter | ||
Comment 25•12 years ago
|
||
I also tried installing the 5/28 Nightly and opening 50+ GMail tabs, then going to Help -> About and restarting to update. I can watch firefox.exe take a long time to close (in Task Manager) but it does close cleanly and restarts with the update without an issue.
Assignee | ||
Comment 26•12 years ago
|
||
As discussed on irc.
Comment 27•12 years ago
|
||
Comment on attachment 628861 [details] [diff] [review] Attempt to retry the replace operation if it fails for some reason on Windows Review of attachment 628861 [details] [diff] [review]: ----------------------------------------------------------------- ::: toolkit/mozapps/update/updater/updater.cpp @@ +1821,5 @@ > + // Therefore we wait a little bit here to see if the handle is released. > + // If it's not released, we just fail to perform the replace request. > + const int max_retries = 10; > + int retries = 0; > + while (rv && (retries++ < max_retries)) { We should break out early when the error doesn't match the one we would expect when there is a handle open (I think 7). @@ +1826,5 @@ > + LOG(("PerformReplaceRequest: sourceDir rename attempt %d failed. " \ > + "File: " LOG_S ". Last error: %d, err: %d\n", retries, > + sourceDir, GetLastError(), rv)); > + > + Sleep(100); We shouldn't sleep if there are no errors
Assignee | ||
Comment 28•12 years ago
|
||
(In reply to Brian R. Bondy [:bbondy] from comment #27) > Comment on attachment 628861 [details] [diff] [review] > Attempt to retry the replace operation if it fails for some reason on Windows > > Review of attachment 628861 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: toolkit/mozapps/update/updater/updater.cpp > @@ +1821,5 @@ > > + // Therefore we wait a little bit here to see if the handle is released. > > + // If it's not released, we just fail to perform the replace request. > > + const int max_retries = 10; > > + int retries = 0; > > + while (rv && (retries++ < max_retries)) { > > We should break out early when the error doesn't match the one we would > expect when there is a handle open (I think 7). Good point (it's EACCES, or 13). > @@ +1826,5 @@ > > + LOG(("PerformReplaceRequest: sourceDir rename attempt %d failed. " \ > > + "File: " LOG_S ". Last error: %d, err: %d\n", retries, > > + sourceDir, GetLastError(), rv)); > > + > > + Sleep(100); > > We shouldn't sleep if there are no errors We don't. The loop condition will prevent against that.
Assignee | ||
Comment 29•12 years ago
|
||
Attachment #629031 -
Flags: review?(robert.bugzilla)
Updated•12 years ago
|
Attachment #628861 -
Flags: review?(robert.bugzilla) → review+
Updated•12 years ago
|
Attachment #629031 -
Flags: review?(robert.bugzilla) → review+
Comment 30•12 years ago
|
||
Comment on attachment 629031 [details] [diff] [review] Address bbondy's comment Review of attachment 629031 [details] [diff] [review]: ----------------------------------------------------------------- ::: toolkit/mozapps/update/updater/updater.cpp @@ +1821,5 @@ > // Therefore we wait a little bit here to see if the handle is released. > // If it's not released, we just fail to perform the replace request. > const int max_retries = 10; > int retries = 0; > + while (rv == EACCES && (retries++ < max_retries)) { NS_trename returns false and sets errno on an error, but rename_file in updater.cpp actually returns WRITE_ERROR which is error code 7, not 13. Please fix and then carry forward the r+.
Attachment #629031 -
Flags: review+
Assignee | ||
Comment 31•12 years ago
|
||
(In reply to Brian R. Bondy [:bbondy] from comment #30) > Comment on attachment 629031 [details] [diff] [review] > Address bbondy's comment > > Review of attachment 629031 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: toolkit/mozapps/update/updater/updater.cpp > @@ +1821,5 @@ > > // Therefore we wait a little bit here to see if the handle is released. > > // If it's not released, we just fail to perform the replace request. > > const int max_retries = 10; > > int retries = 0; > > + while (rv == EACCES && (retries++ < max_retries)) { > > NS_trename returns false and sets errno on an error, but rename_file in > updater.cpp actually returns WRITE_ERROR which is error code 7, not 13. > > Please fix and then carry forward the r+. Ah, you're right!
Assignee | ||
Comment 32•12 years ago
|
||
Attachment #629031 -
Attachment is obsolete: true
Comment 33•12 years ago
|
||
Comment on attachment 629179 [details] [diff] [review] Address bbondy's comment Review of attachment 629179 [details] [diff] [review]: ----------------------------------------------------------------- Looks good, thanks!
Attachment #629179 -
Flags: review+
Assignee | ||
Comment 34•12 years ago
|
||
Attachment #628861 -
Attachment is obsolete: true
Attachment #629179 -
Attachment is obsolete: true
Assignee | ||
Comment 35•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/1a28fcd25143
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
Comment 36•12 years ago
|
||
Can this be reopened? I'm got this around 10 times for yesterday's nightly build and am unable to update to today's nightly build.
Assignee | ||
Comment 37•12 years ago
|
||
(In reply to Paul [sabret00the] from comment #36) > Can this be reopened? I'm got this around 10 times for yesterday's nightly > build and am unable to update to today's nightly build. Bug 760577 is tracking a better fix for this problem.
Comment 38•11 years ago
|
||
I'm seeing this again.
You need to log in
before you can comment on or make changes to this bug.
Description
•