Closed Bug 757717 Opened 12 years ago Closed 12 years ago

About Nightly window says "Update failed" for me after updating to builds that use the background updating system.

Categories

(Toolkit :: Application Update, defect)

x86_64
Windows 8
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 757835

People

(Reporter: KWierso, Assigned: ehsan.akhgari)

References

Details

Attachments

(2 files)

This morning, I installed the Nightly update that was waiting for me. Later in the day, I read that there was a respin, so I manually checked for the update and hit the restart to update button to apply it. Everything appeared to work, though I didn't actually verify that the update successfully applied or changed anything.

Then tonight I read that there was another respin, so I opened the About Nightly window to check for it and apply it. After a second of the window showing "Checking for updates", it changed and said "Update Failed" and included a link to manually download the update. I closed the window and reopened it to try again. Same thing happened. 

I checked about:buildconfig and saw that I was on a build built from cset c20d415ef1b5. 

I flipped app.update.log to true and closed/reopened the About window to see if it showed anything useful, but I only saw two warnings about using XMLHttpRequest improperly. (Does that pref require an application restart to take effect?)

At this point, I closed Firefox completely and restarted it. I opened the error console and saw a number of messages from "AUS:SVC", which got pushed out of scrollback before I could copy them out. (I think I'm still in the broken state, so I'll restart after I post this and see if they show up again.) Opening the About window again, it now shows the "Restart and Update" button for me. I have not clicked this yet.

Checking in about:buildconfig, I'm still on the c20d415ef1b5 cset, so my most recent restart didn't update me.

Looking in %LOCALAPPDATA%\Mozilla\Firefox\Nightly\updates\, I see a folder named "0", a file named "backup-update.log" and a file named "last-update.log". The contents of both of the .log files is just "Performing a background update". The "0" folder only has one file named "update.status", and its contents is just "pending".


I'm going to click the "Restart to Update" button now and see what happens.
Oh, and I'm on a 64-bit installation of Windows 8, using the 32-bit Nightly builds, for what it's worth.
Hrm, updates just got disabled due to issues with the update service, so I can't tell for sure what the error console said, but here's what it says for me with the updates disabled on the server's side: http://pastebin.mozilla.org/1648451

The About window says I'm up to date because the updates are disabled. 

I'm still on that c20d415 cset.
Kwierso confirmed his maintenance service path does not have quotes, it is:
C:\Program Files (x86)\Mozilla Maintenance Service\maintenanceservice.exe

SO the issue described in bug 757711 is not related to this bug.
I bet this is bug 757835.
Whiteboard: [dupe of bug 757835]
Blocks: bgupdates
Kwierso: Can you double verify that your maintenanceservice.exe path in services does NOT have quotes surrounding the path?

If you did have quotes the service error in particular would be from: 
Bug 757711.  You mentioned you didn't though so it wouldn't be that bug.

In either case though, as Ehsan mentioned it sounds like a service error of some sort which is not falling back due to bug 757835.
Also right after you get the update failed, please check what is contained in this file:
"C:\Users\USERNAME\AppData\Local\Mozilla\Firefox\Nightly\updates\0\update.status"
I know you checked update.status above by the way:

>  The "0" folder only has one file named "update.status", and its contents is just "pending".

But you should only have pending after a browser restart, I wanted to know directly after getting the error what is contained there.
Here's what the Maintenance Service looks like for me.
Thanks KWierso, I can confirm 100% it's not related to Bug 757711.
Can you check update.status after getting the error right away?
(In reply to Brian R. Bondy [:bbondy] from comment #6)
> Also right after you get the update failed, please check what is contained
> in this file:
> "C:\Users\USERNAME\AppData\Local\Mozilla\Firefox\Nightly\updates\0\update.
> status"

(In reply to Brian R. Bondy [:bbondy] from comment #7)
> I know you checked update.status above by the way:
> 
> >  The "0" folder only has one file named "update.status", and its contents is just "pending".
> 
> But you should only have pending after a browser restart, I wanted to know
> directly after getting the error what is contained there.

The 0 folder is currently empty, and checking for updates says I'm on the most recent one. Are updates still disabled?

My backup-update.log and last-update.log files haven't been modified since last night, both still say "Performing a background update".
ya crap you won't be able to check until updates are enabled again
Okay, so now that updates are back on, the update failed to apply again.
Both of the *.log files say "Performing a background update" and 0/update.status says "failed: 27".
So 27 is for SERVICE_UPDATER_COMPARE_ERROR, this is known to happen when the service is not updated but the rest of background updates is updated.  It could happen for some other bug too though.
I'm not sure how you could get that though since your service doesn't have quotes around it. 

Could you zip up:
C:\ProgramData\Mozilla\logs and attach here?
Also, can you please see what version of the service you have in C:\Program Files (x86)\Mozilla Maintenance Service\maintenanceservice.exe.
(In reply to Wes Kocher (:KWierso) from comment #14)
> Created attachment 626848 [details]
> logs.zip

Yeah, this is most likely an old version of the service which is not getting upgraded for some reason.
(In reply to Ehsan Akhgari [:ehsan] from comment #15)
> Also, can you please see what version of the service you have in C:\Program
> Files (x86)\Mozilla Maintenance Service\maintenanceservice.exe.

Says it's File version 15.0.0.4525, Product version 15.0a1, with Date modified 5/22/2012 1:25PM.


I also have a C:\Program Files (x86)Mozilla Maintenance Service\maintenanceservice_tmp.exe, which has a File version 13.0.0.4519, Product version 13.0, with a date modified of 5/23/2012 12:24 AM.

I'm guessing the second one is from my Aurora installation or something?
So it seems from your log file that the service wasn't replaced because it is newer than what is being upgraded to.

Is it possible you have a service with a newer version that doesn't have background updates somehow?
> I also have a C:\Program Files (x86)Mozilla Maintenance 
> Service\maintenanceservice_tmp.exe, which has a File version 13.0.0.4519, Product > version 13.0, with a date modified of 5/23/2012 12:24 AM.

That will get copied in when updating aurora and deleted on your next reboot.  Or overwritten on the next software update.  So it's ok to have that there.
Do you have some other channels installed that would also provide v15 version numbers? I'm thinking some other channel that didn't have background updates yet was installed that had a newer version.  

When background updates installed, it didn't replace the service because you already had a newer version one. 

This problem is only present while such channels don't have background updates, so the problem should go away on its own soon.  Normally this would have a fallback to not use the service but background updates broke the fallback. 

I think it's best just to manually turn app.update.stage.enabled; to false and then update again.  Once you are updated reset to the default value of app.update.stage.enabled; which is off.
Please wait for Ehsan to comment though in case he wants to gather any extra info.
(In reply to Brian R. Bondy [:bbondy] from comment #20)
> Do you have some other channels installed that would also provide v15
> version numbers? I'm thinking some other channel that didn't have background
> updates yet was installed that had a newer version.  
Only thing I can think of is that I have the Win8 Metro test build installed as well. I guess that's also version 15?
> Only thing I can think of is that I have the Win8 Metro test build installed as 
> well. I guess that's also version 15?

Yes I'm pretty certain that's what happened. 
I installed an elm build around that time and it has a matching version number to what you have.

So the "background updates" update didn't think it had to update the maintenance service because you already had one installed with the same version.  That one installed with the same version didn't have the background updates enhancements.

We can avoid the general problem of different channels having the same version number by i) making sure the fallback always works, and ii) making sure for new tasks that it will not break updates if there is an old service installed.

My recommendation is the same but please wait for rstrong and ehsan to weigh in here.

> I think it's best just to manually turn app.update.stage.enabled; to false and then update again.  
> Once you are updated reset to the default value of app.update.stage.enabled; which is off.
Correction:

> Once you are updated reset to the default value of app.update.stage.enabled; which is off.

You won't have to do that part because we don't consider "user set" for manually set preferences if they match what the default is.
Yeah, so I think that Wes should just turn off bgupdates for now, update, and leave it off (as it was turned off on mozilla-central for now).

In general, this version checking has bothered me for a long time.  There's no way that we're going to get it right in every case, and expecting to make the service forward-compatible with all of the future changes is just unreasonable.  We should focus on getting the fallback to work.  I also suggest that we should restrict the version check to the first part of the version number only.
> In general, this version checking has bothered me for a long time. 

Bug 720527 is posted to change to 1 service per channel but I think it is such a low priority that we won't get to it anytime soon.

> and expecting to make the service forward-compatible with all of the 
> future changes is just unreasonable.

It doesn't have to be forward compatible it just has to not break updates in that case and have the fallback work.

> I also suggest that we should restrict the version check to the first 
> part of the version number only.

I think that would probably be bad because if there's a minor change like a security fix, we wouldn't have live testing on it for the branch it lands on.

This is only really a problem for mirrored branches that are out of sync for major changes to the updater code, and I think we can be forward looking when reviewing future changes to know that for the time being.
(In reply to Brian R. Bondy [:bbondy] from comment #26)
> > In general, this version checking has bothered me for a long time. 
> 
> Bug 720527 is posted to change to 1 service per channel but I think it is
> such a low priority that we won't get to it anytime soon.

All the more reason why we should do something about this before that happens.  Basically all of the Windows users who use multiple branches are sort of screwed at this point.

> > and expecting to make the service forward-compatible with all of the 
> > future changes is just unreasonable.
> 
> It doesn't have to be forward compatible it just has to not break updates in
> that case and have the fallback work.

The first part of that sentence can be rephrased as forward-compatibility (sort of!).  Anyways, my point was that is not possible to achieve in every case.  But yeah I agree that the fallback path should continue to work.

> > I also suggest that we should restrict the version check to the first 
> > part of the version number only.
> 
> I think that would probably be bad because if there's a minor change like a
> security fix, we wouldn't have live testing on it for the branch it lands on.
> 
> This is only really a problem for mirrored branches that are out of sync for
> major changes to the updater code, and I think we can be forward looking
> when reviewing future changes to know that for the time being.

Yeah you're right...  I don't know what the best option to fix this would be then.  :(
> Basically all of the Windows users who use multiple branches are sort 
> of screwed at this point.

Not at all, for the small amount of people that this effected, they can get an update from a sister branch that will soon enough have the background updates and they'll be fine. 

>  Anyways, my point was that is not possible to achieve in every case.

Yes it is very easy to achieve, don't accept new changes that would break updates :)

Forward thinking means you have to think ahead about how future people will use the service, we just need to think back and make sure it doesn't break if using an old service before landing service changes.   

> Yeah you're right...  I don't know what the best option to fix this 
> would be then.  :(

Bug 720527 might be the best option, but even that I'm not entirely convinced that having so many services is a good idea.
Assignee: nobody → ehsan
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Whiteboard: [dupe of bug 757835]
So just to be clear, I can go ahead and fix my setup now? You don't need anything else from me?
Yup just setting app.update.stage.enabled to false should fix it, thanks for all the info and help KWierso.
Yep.  The bug you were experiencing is well known and fixed on mozilla-central.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: