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
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 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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
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
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@sebastianhahn.net:
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
On 31.07.2020 14:41, William Kane wrote:
That was very informative and educational compared to the other replies.
+1
On 29.07.2020 05:21, ECAN - Matt Westfall wrote:
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.
Is there a (few seconds downtime) threshold , if you reboot after kernel upgrades?
I try to limit the reboots and usually wait until a Tor and kernel upgrade has come out. Of course, I'm not waiting for reboots in the event of serious security vulnerabilities that apply to my system.
Strange, it's still missing the Guard flag after 8 days of consecutive uptime - maybe I'm just being impatient?
Weirdly enough, the relay is also missing on https://utternoncesense.com/consensus-health.html.
Every other relay that I look up can be found on there.
Given that my relay's WOF was 97.95% and 98% are required, this appears very strange to me.
Does this possibly have something to do with the increased traffic / borderline DoS of the DirAuth's caused by the alternative Tor client (not that I know anything about it, I just read about it on this mailing list a few weeks ago)?
I really want my Guard flag back :-(
2020-08-01 11:24 GMT, lists@for-privacy.net lists@for-privacy.net:
On 31.07.2020 14:41, William Kane wrote:
That was very informative and educational compared to the other replies.
+1
On 29.07.2020 05:21, ECAN - Matt Westfall wrote:
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.
Is there a (few seconds downtime) threshold , if you reboot after kernel upgrades?
I try to limit the reboots and usually wait until a Tor and kernel upgrade has come out. Of course, I'm not waiting for reboots in the event of serious security vulnerabilities that apply to my system.
-- ╰_╯ Ciao Marco!
Debian GNU/Linux
It's free software and it gives you freedom!
On 5. Aug 2020, at 17:25, William Kane ttallink@googlemail.com wrote:
Strange, it's still missing the Guard flag after 8 days of consecutive uptime - maybe I'm just being impatient?
Weirdly enough, the relay is also missing on https://utternoncesense.com/consensus-health.html.
Every other relay that I look up can be found on there.
Given that my relay's WOF was 97.95% and 98% are required, this appears very strange to me.
Does this possibly have something to do with the increased traffic / borderline DoS of the DirAuth's caused by the alternative Tor client (not that I know anything about it, I just read about it on this mailing list a few weeks ago)?
I really want my Guard flag back :-(
Hi William,
your current values are:
R 47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF +MTBF 2145977 0.43543 S=2020-07-27 21:47:42 +WFU 2145977 2190729
still shy of 98%.
Additionally, no idea what that website is you linked, but you're listed on https://consensus-health.torproject.org/consensus-health.html
Cheers Sebastian
2145977 of 2190729 are 97.96%.. if it's really changing that slowly, it's gonna take at least another 32 days, seeing that it took 8 days to go from 97.95% to 97.96%..
..thats slow.
Also, thanks for the correct site, I randomly searched "consensus-health" and just used the first site.. dumb mistake on my end.
Thank you and have a great weekend everyone.
2020-08-05 19:27 GMT, Sebastian Hahn mail@sebastianhahn.net:
On 5. Aug 2020, at 17:25, William Kane ttallink@googlemail.com wrote:
Strange, it's still missing the Guard flag after 8 days of consecutive uptime - maybe I'm just being impatient?
Weirdly enough, the relay is also missing on https://utternoncesense.com/consensus-health.html.
Every other relay that I look up can be found on there.
Given that my relay's WOF was 97.95% and 98% are required, this appears very strange to me.
Does this possibly have something to do with the increased traffic / borderline DoS of the DirAuth's caused by the alternative Tor client (not that I know anything about it, I just read about it on this mailing list a few weeks ago)?
I really want my Guard flag back :-(
Hi William,
your current values are:
R 47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF +MTBF 2145977 0.43543 S=2020-07-27 21:47:42 +WFU 2145977 2190729
still shy of 98%.
Additionally, no idea what that website is you linked, but you're listed on https://consensus-health.torproject.org/consensus-health.html
Cheers Sebastian _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Never mind - looks like I got my guard flag back now, yay!
Thanks so much for the help everyone.
William
2020-08-06 0:45 GMT, William Kane ttallink@googlemail.com:
2145977 of 2190729 are 97.96%.. if it's really changing that slowly, it's gonna take at least another 32 days, seeing that it took 8 days to go from 97.95% to 97.96%..
..thats slow.
Also, thanks for the correct site, I randomly searched "consensus-health" and just used the first site.. dumb mistake on my end.
Thank you and have a great weekend everyone.
2020-08-05 19:27 GMT, Sebastian Hahn mail@sebastianhahn.net:
On 5. Aug 2020, at 17:25, William Kane ttallink@googlemail.com wrote:
Strange, it's still missing the Guard flag after 8 days of consecutive uptime - maybe I'm just being impatient?
Weirdly enough, the relay is also missing on https://utternoncesense.com/consensus-health.html.
Every other relay that I look up can be found on there.
Given that my relay's WOF was 97.95% and 98% are required, this appears very strange to me.
Does this possibly have something to do with the increased traffic / borderline DoS of the DirAuth's caused by the alternative Tor client (not that I know anything about it, I just read about it on this mailing list a few weeks ago)?
I really want my Guard flag back :-(
Hi William,
your current values are:
R 47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF +MTBF 2145977 0.43543 S=2020-07-27 21:47:42 +WFU 2145977 2190729
still shy of 98%.
Additionally, no idea what that website is you linked, but you're listed on https://consensus-health.torproject.org/consensus-health.html
Cheers Sebastian _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi William,
you failed to take into account the algorithm that weighs more frequent downtime more than less recent downtime. You seem to have just extrapolated linearly.
Cheers Sebastian
On 8. Aug 2020, at 20:27, William Kane ttallink@googlemail.com wrote:
Never mind - looks like I got my guard flag back now, yay!
Thanks so much for the help everyone.
William
2020-08-06 0:45 GMT, William Kane ttallink@googlemail.com:
2145977 of 2190729 are 97.96%.. if it's really changing that slowly, it's gonna take at least another 32 days, seeing that it took 8 days to go from 97.95% to 97.96%..
..thats slow.
Also, thanks for the correct site, I randomly searched "consensus-health" and just used the first site.. dumb mistake on my end.
Thank you and have a great weekend everyone.
2020-08-05 19:27 GMT, Sebastian Hahn mail@sebastianhahn.net:
On 5. Aug 2020, at 17:25, William Kane ttallink@googlemail.com wrote:
Strange, it's still missing the Guard flag after 8 days of consecutive uptime - maybe I'm just being impatient?
Weirdly enough, the relay is also missing on https://utternoncesense.com/consensus-health.html.
Every other relay that I look up can be found on there.
Given that my relay's WOF was 97.95% and 98% are required, this appears very strange to me.
Does this possibly have something to do with the increased traffic / borderline DoS of the DirAuth's caused by the alternative Tor client (not that I know anything about it, I just read about it on this mailing list a few weeks ago)?
I really want my Guard flag back :-(
Hi William,
your current values are:
R 47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF +MTBF 2145977 0.43543 S=2020-07-27 21:47:42 +WFU 2145977 2190729
still shy of 98%.
Additionally, no idea what that website is you linked, but you're listed on https://consensus-health.torproject.org/consensus-health.html
Cheers Sebastian _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Indeed I did extrapolate linearly - thank you for your high quality answers, not everyone has the time to read every line of the Tor code base and it's documentation.
You are being very helpful and I'm glad I can finally leave this issue behind while having learned some new stuff.
Stay awesome!
William :-)
2020-08-10 15:59 GMT, Sebastian Hahn mail@sebastianhahn.net:
Hi William,
you failed to take into account the algorithm that weighs more frequent downtime more than less recent downtime. You seem to have just extrapolated linearly.
Cheers Sebastian
On 8. Aug 2020, at 20:27, William Kane ttallink@googlemail.com wrote:
Never mind - looks like I got my guard flag back now, yay!
Thanks so much for the help everyone.
William
2020-08-06 0:45 GMT, William Kane ttallink@googlemail.com:
2145977 of 2190729 are 97.96%.. if it's really changing that slowly, it's gonna take at least another 32 days, seeing that it took 8 days to go from 97.95% to 97.96%..
..thats slow.
Also, thanks for the correct site, I randomly searched "consensus-health" and just used the first site.. dumb mistake on my end.
Thank you and have a great weekend everyone.
2020-08-05 19:27 GMT, Sebastian Hahn mail@sebastianhahn.net:
On 5. Aug 2020, at 17:25, William Kane ttallink@googlemail.com wrote:
Strange, it's still missing the Guard flag after 8 days of consecutive uptime - maybe I'm just being impatient?
Weirdly enough, the relay is also missing on https://utternoncesense.com/consensus-health.html.
Every other relay that I look up can be found on there.
Given that my relay's WOF was 97.95% and 98% are required, this appears very strange to me.
Does this possibly have something to do with the increased traffic / borderline DoS of the DirAuth's caused by the alternative Tor client (not that I know anything about it, I just read about it on this mailing list a few weeks ago)?
I really want my Guard flag back :-(
Hi William,
your current values are:
R 47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF +MTBF 2145977 0.43543 S=2020-07-27 21:47:42 +WFU 2145977 2190729
still shy of 98%.
Additionally, no idea what that website is you linked, but you're listed on https://consensus-health.torproject.org/consensus-health.html
Cheers Sebastian _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
ECAN - Matt Westfall -
lists＠for-privacy.net -
Matt Traudt -
Sebastian Hahn -
William Kane