Closed Bug 794211 Opened 12 years ago Closed 12 years ago

[OTA update] Check for updates when online if the network is offline during a check

Categories

(Firefox OS Graveyard :: General, defect, P1)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed)

Status:
RESOLVED FIXED
Project Flags:
blocking-basecamp +
Tracking Flags:
Tracking Status
firefox18 --- fixed
firefox19 --- fixed

People

(Reporter: dietrich, Assigned: marshall)

References

Details

(Whiteboard: ota update)

Attachments

(2 files, 1 obsolete file)

updater script to 2 mins.
1.27 KB, application/x-sh
Details
update online observer - v2
18.91 KB, patch
bbondy
: review+
Details | Diff | Splinter Review 
STR:

1. flash nightly build from >1 days in the past (erases all user data, resets time, everything gone)
2. wait an hour

Expected: in one hour after flashing, see notification saying nightly build update is available

Actual: no notification ever. nothing in adb logcat.
OS: Mac OS X → Gonk
Hardware: x86 → ARM
I was able to successfully update from 9-24 daily to 9-25 today.  a couple things to try:

- be sure wifi is enabled. (yes, i facepalmed on that)
- grab a daily otoro_us build > 9-23-2012
- try forcing the updater time to a shorter time.   i'll attach a script that shortens it to 2 minutes.
- verify the notifications dropdown has the dialog:  "System update available"
thanks. triggering the update via the updater script finally worked. i haven't yet had a successful update without the force-update script.
Several folks on #b2g got them accidentally last night, because we forgot to disable polling for development builds ;).
Whiteboard: ota update
So after a successful update from yesterday's build, i was hoping that today i'd get a new OTA update.  i never saw anything after doing 1 sucessful update.  

I'll try to reproduce today with logcats, but several people have mentioned this as well.   certainly a blocker for dogfooding if we can't serve more than 1 update.
blocking-basecamp: --- → ?
Blocking based on comment #5 and Marshall's comments during triage.
blocking-basecamp: ? → +
(In reply to Tony Chung [:tchung] from comment #5)
> So after a successful update from yesterday's build, i was hoping that today
> i'd get a new OTA update.  i never saw anything after doing 1 sucessful
> update.  
> 
> I'll try to reproduce today with logcats, but several people have mentioned
> this as well.   certainly a blocker for dogfooding if we can't serve more
> than 1 update.

Here's a logcat of what i'm seeing when trying an update after an update.  it seems to think i'm offline.

10-03 08:11:50.066: I/Gecko(5938): *** AUS:SVC Checker:getUpdateURL - update URL: http://update.boot2gecko.org/nightly/update.xml
10-03 08:11:50.066: E/GeckoConsole(5938): AUS:SVC Checker:getUpdateURL - update URL: http://update.boot2gecko.org/nightly/update.xml
10-03 08:11:50.066: I/Gecko(5938): *** AUS:SVC gCanCheckForUpdates - able to check for updates
10-03 08:11:50.066: E/GeckoConsole(5938): AUS:SVC gCanCheckForUpdates - able to check for updates
10-03 08:11:50.066: I/Gecko(5938): *** AUS:SVC Checker:checkForUpdates - sending request to: http://update.boot2gecko.org/nightly/update.xml
10-03 08:11:50.066: E/GeckoConsole(5938): AUS:SVC Checker:checkForUpdates - sending request to: http://update.boot2gecko.org/nightly/update.xml
10-03 08:11:50.276: I/Gecko(5938): *** AUS:SVC Checker:onError - request.status: 2152398864
10-03 08:11:50.276: E/GeckoConsole(5938): AUS:SVC Checker:onError - request.status: 2152398864
10-03 08:11:50.287: I/Gecko(5938): *** AUS:SVC getStatusTextFromCode - transfer error: Network is offline (go online), code: 2152398864
10-03 08:11:50.287: E/GeckoConsole(5938): AUS:SVC getStatusTextFromCode - transfer error: Network is offline (go online), code: 2152398864
10-03 08:11:50.287: I/Gecko(5938): *** AUS:SVC UpdateService:notify:listener - error during background update: Network is offline (go online)
10-03 08:11:50.287: E/GeckoConsole(5938): AUS:SVC UpdateService:notify:listener - error during background update: Network is offline (go online)
The "Network is offline" message happens when there isn't a data connection available (at least, that is the intention.) This is relatively new behavior that originates from this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=777145

Tony, are you on wifi when testing updates, or only cell data?

CCing Hub
I'm generally only ever on wifi so that could explain why I've yet to receive an update prompt.
(In reply to Marshall Culpepper [:marshall_law] from comment #8)
> The "Network is offline" message happens when there isn't a data connection
> available (at least, that is the intention.) This is relatively new behavior
> that originates from this bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=777145
> 
> Tony, are you on wifi when testing updates, or only cell data?
> 
> CCing Hub

I've only been testing on Wifi for this.  i confirm and made sure that my wifi was connected and stably working.   So i'm not sure why the AUS:svc logcat thinks im offline.

On my radar to test over carrier, but i was under the impression carrier data updates was not supported for v1.
"offline" should be false over wifi if you have a proper wifi connection. I don't have data on my phone either so I get wifi.

I remember seeing these "AUS:SVC" messages about being offline. On the other hand the browser works.

Also it should be noted I have only tested this on a Samsung Galaxy S2 as it is the only hardware I have to test.
Attached patch update online observer - v1 (obsolete) — — Splinter Review 
This should mitigate "missing the update window" errors when a B2G device is offline.
We might want to have similar short-circuit behavior for other errors too, but it
isn't clear to me right now what those might be.
Attachment #667707 - Flags: review?(robert.bugzilla)
I just looked at logcat *while* restarting with the force-check script and saw this sequence:

1. restart
2. watch system check for updates and get the offline error almost *immediately* after restarting (note: just ran force-check script, so prefs are what, 2 mins now?)
3. watch system go online to known wifi *after* the update check
Assignee: nobody → marshall
Confirmed. Updated the force-check script to wait 30 seconds (instead of 10) and update worked. The system had enough time for wifi autoconnect to finish, and then the update check occurred.

Note, all of this is separate from the fact that even after setting the update check interval to 2 mins, it only ever occurs *once*.
Dietrich / Tony. The attached script doesn't change the app.update.interval, which should still be set to 86400 (once per day). 

Are you guys using a different script that sets app.update.interval, or only changing app.update.timerFirstInterval?
Hrm, no. was just my misunderstanding. i thought Tony said 2 min interval, but the script i have doesn't actually do that.
(In reply to Dietrich Ayala (:dietrich) from comment #16)
> Hrm, no. was just my misunderstanding. i thought Tony said 2 min interval,
> but the script i have doesn't actually do that.

phew :)

That might explain why you're only seeing the update check "once" -- it only happens once per day after the initial check. My attached patch should fix the case when the update check fails because the device is offline. Once this is landed, we should check immediately once the device comes online again.

Have either of you seen the update _check_ fail for any other reason? Note I'm not talking about the download or application of the update here, just the ping to update.xml.
So, what happens if the device is offline for multiple days? It looks like it calls _registerOnlineObserver once for each check interval
Comment on attachment 667707 [details] [diff] [review]
update online observer - v1

Minus due to comment #18
Attachment #667707 - Flags: review?(robert.bugzilla) → review-
(In reply to Marshall Culpepper [:marshall_law] from comment #17)
> (In reply to Dietrich Ayala (:dietrich) from comment #16)
> > Hrm, no. was just my misunderstanding. i thought Tony said 2 min interval,
> > but the script i have doesn't actually do that.
> 
> phew :)
> 
> That might explain why you're only seeing the update check "once" -- it only
> happens once per day after the initial check. My attached patch should fix
> the case when the update check fails because the device is offline. Once
> this is landed, we should check immediately once the device comes online
> again.
> 
> Have either of you seen the update _check_ fail for any other reason? Note
> I'm not talking about the download or application of the update here, just
> the ping to update.xml.

i haven't seen any other errors, but then again i havent been looking for them within 24 hours.  is there a way i can set my own app.update.interval on the device? if so, where?
Severity: normal → critical
Priority: -- → P1
Cleaned up logic based on rstrong's comments. Added a new xpcshell test for the
new fallback behavior (verified on b2g desktop). Moved the nsIUpdateCheckListener
impl directly into UpdateService so onError can be forwarded to from xpcshell
tests.
Attachment #667707 - Attachment is obsolete: true
Attachment #669848 - Flags: review?(netzen)
Looks like my new test is timing out for non-b2g desktop builds:
https://tbpl.mozilla.org/php/getParsedLog.php?id=15976241&tree=Try

Not sure why this would happen, I'll try spinning up a desktop Fx build today to debug it.
Blocks: 798948
Comment on attachment 669848 [details] [diff] [review]
update online observer - v2

Review of attachment 669848 [details] [diff] [review]:
-----------------------------------------------------------------

I only skimmed the test but the implementation of the task itself looks good to me. 
I think rs mentioned on IRC that he wanted to review this after me.

::: toolkit/mozapps/update/nsUpdateService.js
@@ +1858,5 @@
> +      errCount = getPref("getIntPref", PREF_APP_UPDATE_BACKGROUNDERRORS, 0);
> +      errCount++;
> +      Services.prefs.setIntPref(PREF_APP_UPDATE_BACKGROUNDERRORS, errCount);
> +      maxErrors = getPref("getIntPref", PREF_APP_UPDATE_BACKGROUNDMAXERRORS,
> +                         10);

nit: I think you can just put the 10 on the previous line, if it's > 80 then align it 1 more space to the right.
Attachment #669848 - Flags: review?(netzen) → review+
Attachment #669848 - Flags: review?(robert.bugzilla)
The hangout from my previous TBPL run turned out to be because of app.update.auto being true for Fx. My test now sets it to false, and uses the localhost override URL to skip any cert checks. I've confirmed this is now passing for Fx desktop on OS X 10.7, and I've spun up a new Try build to confirm:

https://tbpl.mozilla.org/?tree=Try&rev=15651fec00ce
Comment on attachment 669848 [details] [diff] [review]
update online observer - v2

Note: I asked Marshall to check with bbondy to see if he felt this needed another review and if he does to ask Ehsan if he could review this. So, clearing review request.
Attachment #669848 - Flags: review?(robert.bugzilla)
Brian feels comfortable with his review, so just awaiting the Try results (hurray for two outages in one day!) and I will be pushing to inbound
Updated the title of this bug to reflect what the attached patch is actually doing.
Summary: [OTA update] never receive update notification using nightly builds → [OTA update] Check for updates when online if the network is offline during a check
Try run for 15651fec00ce is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=15651fec00ce
Results (out of 1148 total builds):
    exception: 95
    success: 584
    warnings: 32
    failure: 437
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mculpepper@mozilla.com-15651fec00ce
FYI, it looks to me like we now (since a few days ago) turn off wifi when the phone turns off the screen (I guess to save energy), so we are offline almost all the time and it's almost impossible to get an update at all without the bug here being fixed.
My try run happened during 2 outages, but the all-important xpcshell tests are passing for all the desktop platforms now.  Landing this and Bug 798948 together
https://hg.mozilla.org/mozilla-central/rev/a2be97f8e874
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Blocks: 801742
Blocks: 801987
Blocks: 802016
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: