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@sebastianhahn.net To: tor-relays@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@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/47E1157F7DA6DF80EC00D745D73AC...
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays