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

RESOLVED FIXED

Status

Firefox OS
General
P1
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: dietrich, Assigned: marshall_law)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

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

Details

(Whiteboard: ota update)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
OS: Mac OS X → Gonk
Hardware: x86 → ARM

Comment 1

5 years ago
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"

Comment 2

5 years ago
Created attachment 664627 [details]
updater script to 2 mins.
(Reporter)

Comment 3

5 years ago
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 ;).

Updated

5 years ago
Whiteboard: ota update

Comment 5

5 years ago
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: ? → +

Comment 7

5 years ago
(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)
(Assignee)

Comment 8

5 years ago
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.
(Assignee)

Comment 12

5 years ago
Created attachment 667707 [details] [diff] [review]
update online observer - v1

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)
(Reporter)

Comment 13

5 years ago
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)

Updated

5 years ago
Assignee: nobody → marshall
(Reporter)

Comment 14

5 years ago
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*.
(Assignee)

Comment 15

5 years ago
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?
(Reporter)

Comment 16

5 years ago
Hrm, no. was just my misunderstanding. i thought Tony said 2 min interval, but the script i have doesn't actually do that.
(Assignee)

Comment 17

5 years ago
(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?
(Reporter)

Updated

5 years ago
Severity: normal → critical
Priority: -- → P1
(Assignee)

Comment 21

5 years ago
Created attachment 669848 [details] [diff] [review]
update online observer - v2

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)
(Assignee)

Comment 22

5 years ago
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.
(Assignee)

Updated

5 years ago
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+
(Assignee)

Updated

5 years ago
Attachment #669848 - Flags: review?(robert.bugzilla)
(Assignee)

Comment 24

5 years ago
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)
(Assignee)

Comment 26

5 years ago
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
(Assignee)

Comment 27

5 years ago
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

Comment 28

5 years ago
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

Comment 29

5 years ago
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.
(Assignee)

Comment 30

5 years ago
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
Last Resolved: 5 years ago
Resolution: --- → FIXED
https://hg.mozilla.org/releases/mozilla-aurora/rev/171b9f02347a
status-firefox18: --- → fixed
status-firefox19: --- → fixed

Updated

5 years ago
Blocks: 801742

Updated

5 years ago
Blocks: 801987

Updated

5 years ago
Blocks: 802016
You need to log in before you can comment on or make changes to this bug.