[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs