[tor-relays] Guard flag got removed after only 48 hours of downtime.

ECAN - Matt Westfall mwestfall at ecansol.com
Wed Jul 29 03:21:43 UTC 2020


Yeah you wouldn't want to instantly throw a relay the Guard flag back 
after any kind of down time, because the whole point of a Guard is 
primarily stability.

If a Guard drops off line for even 10 minutes, there's no way to know 
why.

Network event?
Power Outage?
Any number of other problems?

So when it shows back up, the metrics want to makes sure it's going to 
stay up before giving it Guard back :-D

Thanks,

Matt Westfall
President & CIO
ECAN Solutions, Inc.
Everything Computers and Networks
804.592.1672

------ Original Message ------
From: "Sebastian Hahn" <mail at sebastianhahn.net>
To: tor-relays at lists.torproject.org
Sent: 7/28/2020 11:18:14 PM
Subject: Re: [tor-relays] Guard flag got removed after only 48 hours of 
downtime.

>Hi William,
>
>>  On 29. Jul 2020, at 00:45, Matt Traudt <pastly at torproject.org> wrote:
>>
>>  The Guard flag conditions are
>>https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2640
>>
>>  Given you're Fast and Stable, and have a good advertised bandwidth and
>>  weight, then I suspect you simply no longer have a Weighted Fractional
>>  Uptime that is at least the median for "familiar" relays.
>>
>>  Thus just give it time.
>>
>>  This has nothing to do with volunteering to be a fallback directory mirror.
>>
>>  Thanks for running a relay, and for doing so at an unpopular provider.
>>
>>  On 7/28/20 9:29 AM, William Kane wrote:
>>>  Please discard the previous (empty) email, it was an error on my end.
>>>
>>>  Today, I noticed that my guard flag has been taken away:
>>>
>>>https://metrics.torproject.org/rs.html#details/47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF
>>>
>>>  Does this have to do with the recent two, major downtime's of the relay?
>>>
>>>  While I wasn't monitoring the server, the kernel decided (or rather
>>>  oom-killer did) to reap the tor process for consuming too much memory
>>>  (keep in mind, this is a virtual machine with only 1GB of RAM which
>>>  running another daemon consuming about ~92MB's of RAM).
>>>
>>>  I promptly restarted the relay, but the same thing happened again yesterday.
>>>
>>>  So today, I manually set a lower MaxMemInQueues value instead of
>>>  letting Tor calculate one for me - 640MB's instead of 732MB's.
>>>
>>>  Still, I am confused as for why the guard flag has been taken away - I
>>>  recently opted in to be a fallback directory mirror, does this have
>>>  anything to do with it?
>>>
>>>  The relay was stable and online for almost a year, so only 48 hours of
>>>  downtime shouldn't affect the variables qualifying a relay to become
>>>  and stay a guard that much?
>>>
>>>  If this is because of the directory mirror thing, then please take my
>>>  relay out of that pool - I want to stay a guard for a number of
>>>  reasons - mainly because my host is only hosting about 10 tor relays
>>>  unlike all the other big hosters that are commonly used - network
>>>  variety is very important or so I've been taught, especially when it
>>>  comes to guard relays.
>>>
>>>  If this is a mistake on Tor Project's end, I please ask for it to be
>>>  resolved - however, if it's the Directory Authorities disqualifying my
>>>  relay, then there's nothing to be done except to wait.
>>>
>>>  Greetings,
>>>  William Kane
>
>according to gabelmoo's vote, it requires:
>flag-thresholds stable-uptime=1202114 stable-mtbf=3679804 fast-speed=102000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=18400000 guard-bw-exc-exits=14400000 enough-mtbf=1 ignoring-advertised-bws=1
>
>gabelmoo assigns your relay the following values:
>R 47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF
>+MTBF 4632038 0.93987 S=2020-07-27 21:47:42
>+WFU 4632038 4728633
>
>As you can see, you barely do not make the WFU (required: 98%, you have
>97.95%). Note that more recent downtimes are given more weight (that's
>what the W stands for in WFU). Very soon your flag should be back.
>
>Cheers
>Sebastian
>
>
>
>_______________________________________________
>tor-relays mailing list
>tor-relays at lists.torproject.org
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



More information about the tor-relays mailing list