Opened 5 months ago

Closed 4 months ago

#26987 closed defect (not a bug)

Tor seems to be reading from two different time sources in a macOS VM

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: 0.3.4.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: macos, tor-time
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I started chutney (and its tors) a few minutes after resuming from sleep, but Tor sometimes gets the time wrong by 15 hours. (Which is approximately the time the VM last slept.)

I wonder if we're using the wrong macOS time APIs?
Or it could be a VM or macOS issue.

FAIL: ipv6-exit-min
Detail: chutney/tools/warnings.sh /Users/base/chutney/net/nodes.1532996702
Warning: Couldn't store my own vote! (I told myself, 'Bad valid-after time'.) Number: 2
Warning: Rejecting vote from 127.0.0.1 with valid-after time of 2018-07-31 00:26:05; we were expecting 2018-07-31 00:25:10 Number: 2
Warning: Your system clock just jumped 55189 seconds backward; assuming established circuits no longer work. Number: 3
Warning: Your system clock just jumped 55191 seconds forward; assuming established circuits no longer work. Number: 3

Child Tickets

Attachments (1)

nodes.1532996702.zip (126.9 KB) - added by teor 5 months ago.
chutney nodes directory

Download all attachments as: .zip

Change History (6)

Changed 5 months ago by teor

Attachment: nodes.1532996702.zip added

chutney nodes directory

comment:1 Changed 4 months ago by teor

Another set of chutney logs:

FAIL: basic-min
Detail: chutney/tools/warnings.sh /Users/base/chutney/net/nodes.1534738534
Warning: Our clock is 8 days, 20 hours, 33 minutes behind the time published in the consensus network status document (2018-08-20 04:15:50 UTC).  Tor needs an accurate clock to work correctly. Please check your time and date settings! Number: 1
Warning: Problem bootstrapping. Stuck at 45%: Asking for relay descriptors for internal paths. (Clock skew -765211 in microdesc flavor consensus from CONSENSUS; CLOCK_SKEW; count 1; recommendation warn; host ? at ?) Number: 1
Warning: Received a bad CERTS cell from 127.0.0.1:5000: Invalid certificate chain! Number: 1
Warning: Received a bad CERTS cell from 127.0.0.1:5002: Invalid certificate chain! Number: 1
Warning: Received a bad CERTS cell: At least one certificate expired. Number: 2
Warning: Received microdesc flavor consensus with skewed time (CONSENSUS): It seems that our clock is behind by 8 days, 20 hours, 33 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. Number: 1
Warning: Your system clock just jumped 765219 seconds backward; assuming established circuits no longer work. Number: 3
Warning: Your system clock just jumped 765221 seconds forward; assuming established circuits no longer work. Number: 3
Warning: http status 400 ("Rejected: Your clock is set too far in the future, or your timezone is not correct.") response from dirserver '127.0.0.1:7000'. Please correct. Number: 1
Warning: http status 400 ("Rejected: Your clock is set too far in the future, or your timezone is not correct.") response from dirserver '127.0.0.1:7001'. Please correct. Number: 1

comment:2 Changed 4 months ago by nickm

I am thinking this is not an 0.3.4 blocker if it is VM-only, but it would be good to fix.

comment:3 Changed 4 months ago by nickm

I had thought that this might be a problem with our use of mach_approximate_time(), but apparently we started using that in 0.3.4 to no ill effect.

Maybe it has something to do with our change in how we update the current time in 0.3.4 with #26009-- that does seem like a relevant change.

comment:4 Changed 4 months ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.4.x-final

comment:5 Changed 4 months ago by teor

Resolution: not a bug
Status: newclosed

This isn't a tor bug:

checking whether build environment is sane... configure: error: newly created file is older than distributed files!
Check your system clock

It's a bug in the VM's time synchronisation, that happens when the VM's time is weeks behind the host's time (oops!). I've turned off the buggy feature, so I think this issue is solved.

Note: See TracTickets for help on using tickets.