1040588 - FindMyDevice doesn't shut down itself as expected.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: FindMyDevice, defect)

Description

[[:fabrice] Fabrice Desré]

STR:
- enable FMD
- go to the website to track the device, wait until you get a position.
- log out of the website.
- run |watch -n1 adb shell b2g-info| to check which apps are running.

Expected:
FMD should close itself after some delay past the last transmission or push message.

Observed:
FMD never closed itself during the ~20min I let it run.

Comment 1

[Guilherme Gonçalves [:ggp]]

This shouldn't be too hard to fix once we get bug 1038881 right. Basically FMD can close itself as soon as it's holding no more wakelocks.

Comment 2

[Jason Smith [:jsmith]]

Fabrice - If an app stays alive when it shouldn't, then the user impact is related to unnecessary power use, right? Or are there other potential impacts here?

Comment 3

[[:fabrice] Fabrice Desré]

(In reply to Jason Smith [:jsmith] from comment #2)
> Fabrice - If an app stays alive when it shouldn't, then the user impact is
> related to unnecessary power use, right? Or are there other potential
> impacts here?

The main impact would be power usage especially if the gps is turned on.
Initially I filed this bug when investigating how to prevent fmd to be killed by the lmk too early, and one solution was to make it run in the parent process. However this meant that we absolutely would need to shutdown the app properly to not bloat the parent forever.

Comment 4

[Jason Smith [:jsmith]]

Jon - Can you weigh in on this bug if you think this is a blocker from a power perspective?

Comment 5

[Jon Hylands [:jhylands]]

Can someone give me the exact name of/link to the application I'm supposed to test? In the marketplace there is nothing called "FindMyDevice". There's something called "Find Me Google", but that doesn't sound like the same thing...

Comment 6

[Jon Hylands [:jhylands]]

I found the whole FindMyDevice thing, but I can't get to the website http://find.firefox.com - it just spins forever saying "Connecting". Is there something special I have to do to get to that website?

Comment 7

[Guilherme Gonçalves [:ggp]]

(In reply to Jon Hylands [:jhylands] from comment #6)
> I found the whole FindMyDevice thing, but I can't get to the website
> http://find.firefox.com - it just spins forever saying "Connecting". Is
> there something special I have to do to get to that website?

If you registered on the device with the same account you logged in on the website, it
should have worked. The "Connecting" thing can either be caused by geolocation failures
(they're quite frequent on the Flame), or some infrastructure problems we had yesterday.

One thing you can try is to issue commands (like "Ring") from the website even as it spins
-- that should work if geolocation is the problem. If you have a logcat with Gaia debug
traces enabled, it could help toubleshoot. Also feel free to join #wmf to talk in real time
if you need.

Comment 8

[Jon Hylands [:jhylands]]

So far, I've been completely unable to look at this - the FindMyDevice server doesn't appear to work very well. I've been using latest 2.0 on my phone, and when I enable FindMyDevice, I get this in logcat:

I/GeckoDump( 1087): [findmydevice] logged in to FxA
I/GeckoDump( 1087): [findmydevice] got wake up request
I/GeckoDump( 1087): [findmydevice] enabled, trying to reach the server
I/GeckoDump( 1087): [findmydevice] begin high priority section, reason: "clientLogic"
I/GeckoDump( 1087): [findmydevice] acquiring one wakelock, wakelocks are: {"clientLogic":[],"command":[]}
I/GeckoDump( 1087): [findmydevice] end high priority section, reason: "clientLogic"
I/GeckoDump( 1087): [findmydevice] releasing one wakelock, wakelocks are: {"clientLogic":[{}],"command":[]}

with nothing else. I'll keep trying periodically, but if I can't get it to work, there's no way to comment on its power usage.

Comment 9

[bhavana bajaj [:bajaj]]

ggp, any other tips you may have here ? I thought we had a stable server at this point, do you know why JOn is running into issues?

Comment 10

[Mark Goodwin [:mgoodwin]]

(In reply to bhavana bajaj [:bajaj] from comment #9)
> ggp, any other tips you may have here ? I thought we had a stable server at
> this point, do you know why JOn is running into issues?

I think jrconlin is the best person to comment on server stability.

Comment 11

[Jon Hylands [:jhylands]]

Attachment: Browser View

This is what the browser does when I log in - it just sits and spins.

Comment 12

[Jon Hylands [:jhylands]]

Attachment: Phone View

This is what my phone looks like (Flame, running a late 2.0 build). Both the phone and my desktop are on the same LAN.

Comment 13

[JR Conlin [:jrconlin,:jconlin]]

Hmm. The server has not changed. SimplePush is reporting no problems, and I see the push requests have gone out from the UI. I have not seen the device pull commands from the server. 

jhylands: please check to see if the device is online (either wifi or the data portion of the phone connection is active). There is a known issue where devices that are asleep for long periods may shut down all radios resulting in them being unreachable.

Comment 14

[Jon Hylands [:jhylands]]

The device is on wifi (my network at home). The screen is on, but the website never finds the phone.

I can produce logs for you if you like - just let me know specifically what you want.

Comment 15

[JR Conlin [:jrconlin,:jconlin]]

Very strange. Your device hasn't picked up any commands from the server for nearly 2 hours. I've sent a few manual push requests as well as sent a few test push queries through the system successfully. I'm a bit at a loss as to what might be going on. Normally, this sort of thing is due to network problems, but if your device is live, then there shouldn't be a problem. You might want to open a browser on the device and just check that it's able to connect to "https://push.services.mozilla.com/status/". 

Failing that, I'm not sure. You might want to check the local log to see if the push messages are being picked up in case something broke and their being lost. The find server hasn't been touched in weeks.

Comment 16

[Kate Glazko]

(In reply to Jon Hylands [:jhylands] from comment #14)
> The device is on wifi (my network at home). The screen is on, but the
> website never finds the phone.
> 
> I can produce logs for you if you like - just let me know specifically what
> you want.

Are you using a new or old Firefox account for this test?

Comment 17

[Jon Hylands [:jhylands]]

Its a brand new account I just created last week.

Connecting to that URL from the phone gives me the same message I get from my desktop:

"not websocket protocol"

The device has nothing in logcat right now that mentions "findmydevice"

Comment 18

[Lawrence Mandel [:lmandel] (use needinfo)]

Fabrice - Triage is having trouble deciding if this should block 2.0. As you filed the bug, do you think think should block 2.0?

Comment 19

[Kate Glazko]

(In reply to Jon Hylands [:jhylands] from comment #17)
> Its a brand new account I just created last week.
> 
> Connecting to that URL from the phone gives me the same message I get from
> my desktop:
> 
> "not websocket protocol"
> 
> The device has nothing in logcat right now that mentions "findmydevice"

Jon, can you try toggling the Enable/Disable toggle in the FMD section of settings and report what you see in the Logcat?

Comment 20

[Jon Hylands [:jhylands]]

https://pastebin.mozilla.org/5714405

Comment 21

[Jon Hylands [:jhylands]]

Attachment: Logcat

Here it is as an attachment...

Comment 22

[Jon Hylands [:jhylands]]

Okay, so I finally got this working - had to create a new account with another email address.

From the phone's perspective, when I have FMD enabled, and I "ring" the device, I can see that event happen on my ammeter GUI. I wait about 10 seconds, and then power down the screen. Over the next ten minutes (which is how long wifi takes before it auto shuts down), the phone is consuming an average of 39.6 mA. Once the ten minutes is up, wifi shuts off, and power usage drops to virtually nothing.

I disabled FMD, rebooted the phone, and then powered down the screen. Again after ten minutes, wifi shut down, and power consumption dropped to nothing. Average power consumed during the ten minute period was 40.3 mA, which is pretty much the same.

So, based on that, I see no reason to block for power...

Comment 23

[[:fabrice] Fabrice Desré]

(In reply to Lawrence Mandel [:lmandel] from comment #18)
> Fabrice - Triage is having trouble deciding if this should block 2.0. As you
> filed the bug, do you think think should block 2.0?

according to comment 22 that does not look bad enough to block.

Comment 24

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Fabrice Desré [:fabrice] from comment #23)
> according to comment 22 that does not look bad enough to block.

Agreed. I have cleared the blocking nom.

Comment 25

[Guilherme Gonçalves [:ggp]]

Attachment: gaia pull request

Adding a tentative/work in progress/proof of concept pull request, since it looks like we're closer to eliminating wakelock leaks.

Comment 26

[:gerard-majax]

(In reply to Jon Hylands [:jhylands] from comment #22)
> Okay, so I finally got this working - had to create a new account with
> another email address.
> 
> From the phone's perspective, when I have FMD enabled, and I "ring" the
> device, I can see that event happen on my ammeter GUI. I wait about 10
> seconds, and then power down the screen. Over the next ten minutes (which is
> how long wifi takes before it auto shuts down), the phone is consuming an
> average of 39.6 mA. Once the ten minutes is up, wifi shuts off, and power
> usage drops to virtually nothing.
> 
> I disabled FMD, rebooted the phone, and then powered down the screen. Again
> after ten minutes, wifi shut down, and power consumption dropped to nothing.
> Average power consumed during the ten minute period was 40.3 mA, which is
> pretty much the same.
> 
> So, based on that, I see no reason to block for power...

I noticed that we do not power off data connection when the screen turns off. Are you sure this will not lead to issues in this case ?

Comment 27

[Jon Hylands [:jhylands]]

The wifi connection gets powered down after 10 minutes of screen-off, and that is independent of FMD.

Comment 28

[:gerard-majax]

(In reply to Jon Hylands [:jhylands] from comment #27)
> The wifi connection gets powered down after 10 minutes of screen-off, and
> that is independent of FMD.

Which is what you already said and is unrelated to what I stated: I noticed that we do power off wifi, but I also noticed that we do not power off data connection. Hence, I'm wondering if the leak may not become problematic in this case. I know this is unrelated to FMD.

Comment 29

[Jon Hylands [:jhylands]]

Oh, okay, sorry, you're talking about a 3G connection. I don't know what the power behavior of the phone with a data connection (I don't have a sim card with a data plan I can use - my personal sim is a micro-sim, and its too thick with an adapter to fit into the flame socket). I can probably order a SIM card.

Do you need me to redo my power analysis with a data connection rather than a wifi connection?

Comment 30

[:gerard-majax]

(In reply to Jon Hylands [:jhylands] from comment #29)
> Oh, okay, sorry, you're talking about a 3G connection. I don't know what the
> power behavior of the phone with a data connection (I don't have a sim card
> with a data plan I can use - my personal sim is a micro-sim, and its too
> thick with an adapter to fit into the flame socket). I can probably order a
> SIM card.

Use your nails to make it fit into the socket, we did it during the berlin work week with some local SIM card that was a bit too thick :)

> 
> Do you need me to redo my power analysis with a data connection rather than
> a wifi connection?

If you don't mind, yes, I'd like to make sure of this :)

Comment 31

[Jon Hylands [:jhylands]]

I found an SIM adapter that appears to work, so I'll update here once I've redone the power analysis.

Comment 32

[Jon Hylands [:jhylands]]

Well, it worked while I had my personal SIM in the phone. We found a prepaid SIM card that had data available, and I pulled the adapter out, and one of the SIM card pins on the 3G slot broke off, so I'll have to wait until tomorrow to do this when I'm home (where I have several more Flames).

Comment 33

[Jon Hylands [:jhylands]]

What I'm seeing is a steady more-or-less 40mA draw (with lots of spikes) for 900 seconds (15 minutes), followed by a drop back down to almost-zero, in the original bug scenario using 3G instead of wifi.

Comment 34

[:gerard-majax]

Guilherme, what's the status on this ?

Comment 35

[Guilherme Gonçalves [:ggp]]

I haven't done any further work on this after my tentative patch (which may have rotten a little by now), and since this is slated for 2.1, Jared is more likely to to take this, so I'm CC-ing him.

Jared, please let me know if you need any help/information from me on this. Ideally it would be good to make some progress on bug 1053403 before this one to reduce the amount of wakelock juggling we do, I think.

Comment 36

[Dietrich Ayala (:dietrich)]

Hi Michael, there was a triage decision to not block on this, and you subsequently flipped the flag to blocking again. At triage today we decided again to not hold the release for this issue - please explain if it really does need to block!

For reference, here are the criteria for determining blockerness: https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines

Comment 37

[Michael:mtreese]

blocking not needed for this bug.

Comment 39

[BMO Automation]

Firefox OS is not being worked on