[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



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@xxxxxxxxxxxxxxxxx>
To: tor-relays@xxxxxxxxxxxxxxxxxxxx
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@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