823122 - Add settime support to Negatus (aka SUT agent version of b2g)

Status: RESOLVED FIXED

(Testing Graveyard :: SUTAgent, defect)

Description

[Malini Das [:mdas] - Away, not checking bugmail]

By default, after the pandaboard is flashed, it has no knowledge of today's date, or even the right year, which is causing problems. According to dustin, it has no onboard clock. Its date is set incorrectly, so we need to set the date after flashing it so that test applications can at least verify that security certificates are valid for B2G.

Comment 1

[Armen [:armenzg]]

What options do I have available to set the date/time on them?

FTR this is to help some tests and does not necessarily block the whole set of Gaia UI tests.

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

You can use NTP to set the date during startup.  The flashing scripts do this, for example:

http://hg.mozilla.org/build/puppet/file/e2e55d831e6f/modules/bmm/templates/b2g-second-stage.sh.erb#l18

  log "setting time with ntpdate"
  ntpdate -b ntp.build.mozilla.org

the boards have no way to keep track of the time (no RTC), so this can't be "set" when flashing.

Comment 3

[Armen [:armenzg]]

Anyone has any options that I can run after re-imaging?

IIUC ntp does not seem to be an option unless sut or marionette had the ability to use it.

Comment 4

[Armen [:armenzg]]

(In reply to Dustin J. Mitchell [:dustin] from comment #2)
> so this can't be "set" when flashing.

Do you know if mozpool could set it *after* flashing?

Comment 5

[Justin Wood (:Callek)]

I'm unsure if/how well this works on pandas, but SUTAgent has a method to do it, see:
http://mxr.mozilla.org/build/source/tools/sut_tools/sut_lib.py#459

It relies on *us* passing in a date/time though, but that should be easy.

Comment 6

[Dustin J. Mitchell [:dustin] (he/him)]

Mozpool could set it with SUT after imaging, but that feels like a tight coupling to me.  Maybe it would be better for the Buildbot automation to do so?

From what I've heard not all images have SUT (Android, in particular).  Is that true?

Comment 7

[Armen [:armenzg]]

AFAIK all pandas should have SUT on them. B2G one is on version 1.13 and the Android one on 1.15:
Armens-MacBook-Air:~ armenzg$ telnet panda-0810 20701
Trying 10.12.136.89...
Connected to panda-0810.p9.releng.scl1.mozilla.com.
Escape character is '^]'.
$>ver
SUTAgentAndroid Version 1.15

Comment 8

[Armen [:armenzg]]

The b2g version of SUT agent does not seem to have the ability to settime [1].
The Android version of SUT agent has the settime feature [2].

[1]
Armens-MacBook-Air:~ armenzg$ telnet panda-0169 20701
Trying 10.12.128.152...
Connected to panda-0169.p1.releng.scl1.mozilla.com.
Escape character is '^]'.
$>clok    
1356029314
$>settime 2012/12/20 13:47:13
##AGENT-WARNING## unknown command
$>clok
1356029316

[2]
Armens-MacBook-Air:~ armenzg$ telnet panda-0810 20701
Trying 10.12.136.89...
Connected to panda-0810.p9.releng.scl1.mozilla.com.
Escape character is '^]'.
$>clok
1356029355519
$>settime 2012/12/20 13:47:13
2012/12/20 01:47:13:080
$>clok
1356011234676

Comment 9

[Armen [:armenzg]]

Either that or another way to set the time.

Comment 10

[Mark Côté [:mcote]]

Might be possible to do this via exec, but it makes more sense to implement a settime command like the Android agent.  I'll handle that.

(Although why the command takes a datetime string instead of a unix timestamp I dunno... blech)

Comment 11

[Mark Côté [:mcote]]

Dealing with datetime is always like poking at a hornet's nest...

The "clok" command returns UTC time in seconds (Negatus) or milliseconds (Android agent).

The "settime" command on the Android agent sets the date and time in the local timezone.

For example, on a phone here in Montreal,

$>settime 2028/08/19 12:00:00
2028/08/19 12:00:00:149
$>clok
1850313601673
$>

1850313601 is 2028/08/19 16:00:01 UTC, i.e. 2028/08/19 12:00:01 EDT.

This is a flawed approach:  since the timezone is omitted in settime, there is ambiguity at daylight-savings-time crossover points.  For example, it's impossible to tell, without additional info, if 2012/11/04 01:30:00 is in EDT or EST.

In light of this, I'd like to deprecate settime in favour of setutime, which will take a UNIX timestamp, in milliseconds (*without* the promise that the milliseconds part will be respected) in UTC.  setutime and clok will be then reciprocal, at least to the seconds level.

There are also some timezone-specific commands in the Android SUT agent ("tzget" and "tzset").  Are these being used anywhere?

Comment 12

[Armen [:armenzg]]

I like the setutime approach.

I don't know about the timezone commands. Our code does not use tzget:
http://mxr.mozilla.org/build/search?string=tzget
I see that twisted uses tzset for some tests but this is not related to dealing with SUT; AFAICT:
http://mxr.mozilla.org/build/search?string=tzset

Comment 13

[Mark Côté [:mcote]]

Attachment: Add settime and setutime commands

Okay, I added settime for compatibility, but as I mentioned it should be considered deprecated.  The specific problem would be the "repeated" times at the DST-ST boundary, when 1:00 am to 1:59 am are repeated, so the argument would be ambiguous.  It will still work, but the result is undefined (it will end up in either DST or ST).

setutime takes one argument, the number of milliseconds since Jan 1, 1970, in UTC.  The milliseconds are respected, since settimeofday() allows them.

Comment 14

[William Lachance (:wlach)]

Comment on attachment 694998 [details] [diff] [review]
Add settime and setutime commands

lgtm

Comment 15

[Mark Côté [:mcote]]

We should implement setutime in SUTAgentAndroid as well.  I'll take a crack at that.

Comment 16

[Mark Côté [:mcote]]

https://github.com/mozilla/Negatus/commit/7ed4efcee655f605455f9375a4e6c68cd078c459 for Negatus changes.  Need to ensure they get into B2G debug builds.

Comment 17

[Mark Côté [:mcote]]

By the way, I fixed the clok command in Negatus to return milliseconds, as in the Java agent.

Comment 18

[Armen [:armenzg]]

Is this fixed now?

Comment 19

[Mark Côté [:mcote]]

Filed bug 827875 for adding setutime to the Java agent.  We're done here.