Dug into the situation Aeris reported where his kitten1 relay was nixed off the fallback directory list due to a single consensus where the dir-port was published as zero. Quickly found three additional very fast very stable relays where the same thing happened: BF0FB582E37F738CD33C3651125F2772705BB8E8 12-28:17 quadhead C43FA6474A9F071E9120DF63ED6EB8FDBA105234 12-25:03 ArachnideFR5 5665A3904C89E22E971305EE8C1997BCA4123C69 11-15:18 GermanCraft In each case the V2Dir flag and DirPort are removed for a single consensus interval and then restored on the next consensus. Appears that a daemon restart is the trigger. Version update not required. Several possible causes, but the one that comes to mind is the daemon could be briefly pushing a descriptor with V2Dir inactive while completing the reacahability test for that port. This deserves to be researched further and mitigated. A possible solution is to have the script tolerate a single consensus with V2Dir removed and a reset uptime. Alternately the daemon could not push a non-V2Dir descriptor during restart and wait for the reacahability determination. I don't know enough about it to be sure the problem isn't something else. At 19:20 1/12/2016 +0100, Aeris wrote:

...

Are you *absolutely* certain that the config was not fiddled with at the time of this event?

After grepping some logs, seems 13/12 was the day of a Tor upgrade:

2015-12-13 10:47:31 upgrade tor:amd64 0.2.7.5-1~d80.jessie+1 0.2.7.6-1~d80.jessie+1 2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1

Timing is good compare to the 10:48:46 of the consensus !

But I don't remember a config change after that, perhaps only on /usr/share/tor/tor-service-defaults-torrc or on a default config param change ?

And perhaps the Tor reboot cause the DirPort to be temporarily disabled (seems not human, only 2s duration) ?

Regards, -- Aeris