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

[William Kane <ttallink@xxxxxxxxxxxxxx>]

Thank you!

That was very informative and educational compared to the other replies.

Best Regards,
William Kane

2020-07-29 3:18 GMT, Sebastian Hahn <mail@xxxxxxxxxxxxxxxxx>:
> Hi William,
>
>> On 29. Jul 2020, at 00:45, Matt Traudt <pastly@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays