[tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat May 6 13:23:40 UTC 2017


#21969: We're missing descriptors for some of our primary entry guards
--------------------------+------------------------------------
 Reporter:  asn           |          Owner:
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-guard     |  Actual Points:
Parent ID:                |         Points:  1.5
 Reviewer:                |        Sponsor:  SponsorU
--------------------------+------------------------------------

Comment (by alecmuffett):

 Clipped from my comments on tor-dev:

 I am running a cluster of 12 "worker" tor daemons (0.3.0.6) across 6
 machines, under Onionbalance.

 So far, 2x of the worker-onion daemons have gone "stale" - are not
 publishing descriptors, are not reachable from the tor network - even
 though their Log.NOTICE-level logfiles show nothing weird. I've sent
 SIGUSR2 to one of them to enable more verbose logging.

 The only notable message is: `Diagnostic for issue 8387: Found 2 one-hop
 circuits more than 1800 seconds old! Logging 2...` - but all of the
 workers are doing that occasionally, whereas only 2x of them are stale.

 Also: in each case where there is a stale tor-daemon on a machine, the
 other daemon, in a separate directory, is not stale - so, it can't be a
 connectivity issue.

 I did `egrep '(for.some.of.our|now.have.enough)' */tor.log` on the fleet
 of workers; it turns out that **all 12x of the worker daemons** have at
 various points issued the following messages:

 `Our directory information is no longer up-to-date enough to build
 circuits: We're missing descriptors for some of our primary entry guards`

 ...and...

 `I learned some more directory information, but not enough to build a
 circuit: We're missing descriptors for some of our primary entry guards.`

 **HOWEVER the 2x STALE daemons** have not issued a subsequent:

 `We now have enough directory information to build circuits`

 ...so it appears that they, in particular, have given up trying to fetch
 directory information - a state which has persisted for **several days**
 now.

 Sample tor.conf follows

 {{{
 # -*- conf -*-
 # eotk (c) 2017 Alec Muffett

 # template note: here we use TOR_DIR not PROJECT_DIR because of the
 # relocation of Tor directories under `softmap`
 DataDirectory /home/pi/eotk/projects.d/projname.d/hs-2.d
 ControlPort unix:/home/pi/eotk/projects.d/projname.d/hs-2.d/tor-
 control.sock
 PidFile /home/pi/eotk/projects.d/projname.d/hs-2.d/tor.pid
 Log notice file /home/pi/eotk/projects.d/projname.d/hs-2.d/tor.log
 SafeLogging 1
 HeartbeatPeriod 60 minutes
 LongLivedPorts 80,443
 RunAsDaemon 1

 # use single onions
 SocksPort 0 # have to disable this for single onions
 HiddenServiceSingleHopMode 1 # yep, i want single onions
 HiddenServiceNonAnonymousMode 1 # yes, really, honest, i swear

 # softmap
 HiddenServiceDir /home/pi/eotk/projects.d/projname.d/hs-2.d
 HiddenServicePort 80
 unix:/home/pi/eotk/projects.d/projname.d/hs-2.d/port-80.sock
 HiddenServicePort 443
 unix:/home/pi/eotk/projects.d/projname.d/hs-2.d/port-443.sock
 HiddenServiceNumIntroductionPoints 3
 }}}

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21969#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list