Re: [tor-relays] Crashed Relay

2021-11-07 Thread Bleedangel Tor Admin
   If you upgraded tor as a package on your Linux OS recently, it may have overwritten your torrc with defaults? It’s a long shot!Sent from ProtonMail for iOS On Sat, Nov 6, 2021 at 12:52, sysmanager7 via tor-relays  wrote:  I was notified by Uptime Robot that relay 1 of 3 had been shut down. Unfortunately I found this out 12 hours after the fact.guard flag is lost.journalctl -u tor@defaultNov 01 01:03:18 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: I learned some more directory information, but not enough to build a circuit: We need more microdescrors: we have 6178/6618, and can only build 49% of likely paths. (We have 99% of guards bw, 50% of midpoint bw, and 98% of exit bw = 49% of path bw.) ptors: we have 6178/6618, and can only build 49% of likely paths. (We have 99% of guards bw, 50% of midpoint bw, and 98% of exit bw = 49% of path bw.)ived 4371.61 GB. I've received 7345604 connections on IPv4 and 0 on IPv6. I've made 677780 connections with IPv4 and 0 with IPv6.Nov 01 06:47:26 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt aga>Nov 01 06:47:26 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: Delaying directory fetches: We are hibernating or shutting down.Nov 01 06:47:56 ubuntu-s-1vcpu-2gb-nyc1-01 Tor[328387]: Clean shutdown finished. Exiting.Nov 01 06:48:04 ubuntu-s-1vcpu-2gb-nyc1-01 systemd[1]: tor@default.service: Succeeded.Nov 01 06:48:04 ubuntu-s-1vcpu-2gb-nyc1-01 systemd[1]: Stopped Anonymizing overlay network for TCP.This is NOT a first time for the above on this relay, more like a 7th or 8th.CPU usage according to NYX is 90/95%. That has been the last three weeks or so.Prior to that, average CPU usage was 30% or less.Current BW/Burst is 3/4 MBs on torrc and nyx. Prior was BW/Burst 4/5*Me - retired fixed income. Average billing for 3 Digital Ocean Droplets was $40. budget is good with that. Octobers billing - $87.50 I used 10 gb instead of 6Gb. Essentially a $40 overage. It's almost as if, torrc and nyx are being ignored.Sent with ProtonMail Secure Email.




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Overloaded state indicator on relay-search

2021-10-15 Thread Bleedangel Tor Admin
   The problem is that it’s *not* currently overloaded, there’s nothing to see. Maybe you can check your syslogs for anything out of the ordinary system-wide? Sent from ProtonMail for iOS On Thu, Oct 14, 2021 at 10:09, Arlen Yaroslav via tor-relays  wrote:  > I am not sure where you are looking but if you take a look at what>> Onionoo[1] is saying you get>> overload_general_timestamp 163418040>> which means 10/14/2021 03:00:00 UTC, thus today.>> Georg>> [1] https://onionoo.torproject.org/details?limit=4=VinculumGateThanks, I was looking at the cached-descriptors file which I can see now is well out of date.Would anyone have any other suggestions regarding why the relay is overloaded?___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Overloaded state indicator on relay-search

2021-10-14 Thread Bleedangel Tor Admin
   Did you use a lot of ram or cpu power recently? I got flagged as overloaded when I was compiling something and used a lot of cpu.Again, the problem here is that even if you fix it, you won’t know for 3 days. Therefore if you try multiple methods to fix it you won’t know what the problem is.I wholeheartedly believe in more status indicators on the search page:Green - goodRed - offlineYellow - overloaded**Blue - was overloaded within 72 hours ago but currently is not**Sent from ProtonMail for iOS On Thu, Oct 14, 2021 at 09:25, Arlen Yaroslav via tor-relays  wrote:  Hi all,My relay (77D08850C1EE8587451F838D3F49874F75B0B1AC) is showing as overloaded on the Relay Search page:https://metrics.torproject.org/rs.html#details/77D08850C1EE8587451F838D3F49874F75B0B1ACI have enabled MetricsPort and MetricsPortPolicy in the torrc configuration file. I have retrieved the metrics into a file and inspected it but it is still not clear to me what the problem is. The only non-zero values I can see are reason="success" or action="". Nothing sticks out in the process logs either.Can anyone assist?Regards,Arlen___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Bridge showing offline

2021-10-14 Thread Bleedangel Tor Admin
   You are running 0.4.5.8, maybe updating to a newer version of tor will help?Sent from ProtonMail for iOS On Thu, Oct 14, 2021 at 03:02, Georg Koppen  wrote:  Eddie:> Looking at tor metrics, one of my bridges is showing as off-line:> B080140DC1BAB5B86D1CE5A4CA2EF64F20282440>> However, the log isn't showing any issues:>> Oct 14 00:00:28.000 [notice] Tor 0.4.5.8 opening new log file.> Oct 14 00:00:28.000 [notice] Configured hibernation.  This interval> began at 2021-10-14 00:00:00; the scheduled wake-up time was 2021-10-14> 00:00:00; we expect to exhaust our quota for this interval around> 2021-10-15 00:00:00; the next interval begins at 2021-10-15 00:00:00> (all times local)> Oct 14 01:49:40.000 [notice] Heartbeat: Tor's uptime is 124 days 6:00> hours, with 0 circuits open. I've sent 907.23 GB and received 922.28 GB.> I've received 63052 connections on IPv4 and 8375 on IPv6. I've made> 512684 connections with IPv4 and 100974 with IPv6.> Oct 14 01:49:40.000 [notice] While not bootstrapping, fetched this many> bytes: 1801791624 (server descriptor fetch); 175792 (server descriptor> upload); 221750347 (consensus network-status fetch); 10974 (authority> cert fetch); 19905655 (microdescriptor fetch)> Oct 14 01:49:40.000 [notice] Heartbeat: Accounting enabled. Sent: 140.52> MB, Received: 140.69 MB, Used: 281.21 MB / 200.00 GB, Rule: sum. The> current accounting interval ends on 2021-10-15 00:00:00, in 22:10 hours.> Oct 14 01:49:40.000 [notice] Heartbeat: In the last 6 hours, I have seen> 14 unique clients.>> Initially I thought of a previous issue I had with IPv6 connectivity,> but don't think this is the problem here as the 2nd bridge on the same> server is showing on-line.  Also an IPv6 port scan shows the ports for> both bridges as accessible.>> Ideas ??I wonder whether that is another instancehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40424. Hard to tell,though. Does that issue happen regularly?Georg___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Overloaded state indicator on relay-search

2021-10-08 Thread Bleedangel Tor Admin
   Can you link to where I can edit the torproject.org documentation? I cannot find this feature.Thanks Sent from ProtonMail for iOS On Thu, Oct 7, 2021 at 06:48,   wrote:  On Wednesday, October 6, 2021 8:55:01 PM CEST potlatch via tor-relays wrote:> Tor has always been very lax at documentation--both creation and updating.> I've never seen a  thorough site map or directory published.  I think this> discourages folks who would like to start a tor relay.Mmm. I'm a stupid hobby admin with no IT background. Tor entry servers werethe first thing I set up on rented servers in the data center. TheTorRelayGuide on Torproject.org was easy for me.https://community.torproject.org/relay/Debian's sample torrc has always been well documented.And micahflee's tor-relay-bootstrap script is forked a dozen times. A relay canbe set up in just a few minutes.The biggest problem is to find a provider where you can rent cheap unmeteredservers and who allow exit's to operate. In addition, the provider shouldideally be far away from DE-CIX Frankfurt and no or few other Tor serversthere.And don't forget the Tor Project is a Community Project. Everyone can edit theTorproject.org Doku. ;-)I can always recommend these pages to beginners:https://tor-relay.co/https://www.torservers.net/wiki/guides--╰_╯ Ciao Marco!Debian GNU/LinuxIt's free software and it gives you freedom!___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Overloaded state indicator on relay-search

2021-10-06 Thread Bleedangel Tor Admin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is much more informational. Great job!

As someone with mystery "overloaded" problems, i'd recommend / request / beg 
for the following:

1) When the relay is overloaded, a yellow indicator appears on the web page. 
This indicator remains for 72 hours after the overloaded state is remedied.
- This is not helpful in diagnosing anything, because even if the problem is 
solved, it is not evident that the relay is no longer overloaded for 72 hours.
-- once the relay is no longer overloaded, it should have a purple (or any 
other color) "recovery" indicator for 72 hours. At least the relay operator 
would know that the overloaded state has been repaired.

2) metricsport
- This is such an enigma to someone who is not familiar with prometheus, or 
torrc beyond the basics. As a matter of fact, when installing the tor-git 
package on Arch Linux, the man pages dont install automatically, so 'man torrc' 
gives a very helpful:

$ man torrc
No manual entry for torrc

The official tor website, under manuals section, -alpha: 
https://2019.www.torproject.org/docs/tor-manual-dev.html.en
does not include the documentation for metricsport.

i think the troubleshooting guide should contain directions to enable 
metricsport, and how to view the results:

...

To enable metricsport for advanced diagnosis:

In torrc set MetricsPort and MetricsPortPolicy flags as follows:

MetricsPort :
MetricsPortPolicy accept 

it is good policy to only allow connections to the metricsport port from 
localhost as follows:

MetricsPort 127.0.0.1:9035   #This will open the metricsport server 
on port 9035, listening on localhost (127.0.0.1).
MetricsPortPolicy accept 127.0.0.1   #This will allow only localhost 
(127.0.0.0) to query the metricsport server.

Once these are set and the configuration reloaded (via SIGHUP or tor restart), 
the data can be queried as follows:

wget http://127.0.0.1:9035/metrics -O metricsport.txt

This will place a file in the current directory called 'metricsport.txt' that 
can be used to troubleshoot the overloaded relay issues via the information in 
this document

...



‐‐‐ Original Message ‐‐‐

On Tuesday, October 5th, 2021 at 4:33 PM, Silvia/Hiro  
wrote:

> On 10/4/21 1:36 PM, David Goulet wrote:
>
> > On 02 Oct (01:29:56), torix via tor-relays wrote:
> >
> > > My relays (Aramis) marked overloaded don't make any sense either. Two of
> > >
> > > the ones marked with orange are the two with the lowest traffic I have 
> > > (2-5
> > >
> > > MiB/s and 4-9 MiB/s - not pushing any limits here); the third one with 
> > > that
> > >
> > > host has more traffic and is fine.
> > >
> > > So far this indicator seems to be no help to me.
> >
> > Keep in mind that the overload state might not be only about traffic 
> > capacity.
> >
> > Like this page states, there other factors including CPU and memory 
> > pressure.
> >
> > https://support.torproject.org/relay-operators/relay-bridge-overloaded/
> >
> > We are in a continuous process of making it better with feedback from the
> >
> > relay community. It is a hard problem because so many things can change or
> >
> > influence things. And different OSes also makes it challenging.
> >
> > Another thing here to remember, the overload state will be set for 72 hours
> >
> > even if a SINGLE overload event occurred.
> >
> > For more details:
> >
> > https://lists.torproject.org/pipermail/tor-relays/2021-September/019844.html
> >
> > (FYI, we are in the process of adding this information in the support page 
> > ^).
>
> We have now updated the support article at:
>
> https://support.torproject.org/relay-operators/relay-bridge-overloaded/
>
> We have tried to clarify how and why the overloaded state is triggered.
>
> I hope this can help operators understand better why their relays can be
>
> found in this state and how a normal state can be recovered.
>
> Please do let us know what you think.
>
> Cheers,
>
> -hiro
>
> > If you can't find sticking out, that is OK, you can move on and see if it
> >
> > continues to stick. If so, maybe its worth digging more and when 0.4.7 will 
> > be
> >
> > stable, you'll be able to enable the MetricsPort (man tor) to get into the
> >
> > rabbit hole a bit deeper.
> >
> > Cheers!
> >
> > David
> >
> > 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
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wnUEARYKAAYFAmFcv8UAIQkQ07hp34FMyg4WIQSgEMifmnN5ohFWvfnTuGnf
gUzKDudLAP9iwogPbk+q1zBA+90BmT0dSnvq4vR0o8Jpr1H7NmWHQQEAizx8
9zAgec3xOKEM+f4cqgcGDwKUK3OT2P8sFrW0xwE=
=Dp/H
-END PGP SIGNATURE-


publickey - tor@bleedangel.com - 0xA010C89F.asc
Description: application/pgp-keys


publickey - tor@bleedangel.com - 0xA010C89F.asc.sig
Description: PGP signature

Re: [tor-relays] Overloaded state indicator on relay-search

2021-10-04 Thread Bleedangel Tor Admin
   Agreed . My relay is wellBelow all of the thresholds for “overloaded”, for gods sake 64gb ram and 12 cpus should be adequate for a tor relay? 10gb connection?I’ve asked multiple times for help trying to figure this out and have gotten zero response. It seems to be very difficult to get any help with running relays. I’d think the tor community would want exit relays running, and would be more forthcoming with information, but the docs and help sections are almost useless.The troubleshooting page for an overloaded relay mentions running metricsport, but with no instructions or even links to anywhere to explain how to do this.The relay search/status website shows 2 extra links below some relays but not others, I get no extra info on mine.My relay has a dirport of 9030 in my config and nyx confirms this. The relay status website says I have no dirport configured.There are so many little issues at play, you’d think this would be simpler to have everything running.Sent from ProtonMail for iOS On Fri, Oct 1, 2021 at 21:29, torix via tor-relays  wrote:  My relays (Aramis) marked overloaded don't make any sense either.  Two of the ones marked with orange are the two with the lowest traffic I have (2-5 MiB/s and 4-9 MiB/s - not pushing any limits here); the third one with that  host has more traffic and is fine.So far this indicator seems to be no help to me.--TorixSent with ProtonMail Secure Email.‐‐‐ Original Message ‐‐‐On Friday, October 1st, 2021 at 12:22 PM, David Goulet  wrote:> On 01 Oct (03:08:20), Andreas Kempe wrote:>> > Hello David!> >> > On Mon, Sep 27, 2021 at 08:22:08AM -0400, David Goulet wrote:> >> > > On 24 Sep (12:36:17), li...@for-privacy.net wrote:> > >> > > > On Thursday, September 23, 2021 3:39:08 PM CEST Silvia/Hiro wrote:> > > >> > > > > When a relay is in the overloaded state we show an amber dot next to the> > > > >> > > > > relay nickname.> > > > >> > > > > Nice thing. This flag has noticed me a few days ago.> > > >> > > > > If you noticed your relay is overloaded, please check the following> > > > >> > > > > support article to find out how you can recover to a "normal" state:> > > > >> > > > > https://support.torproject.org/relay-operators/relay-bridge-overloaded/> > > > >> > > >> > > > A question about Enabling Metricsport. Is definitely Prometheus necessary?> > > >> > > > Or can the Metrics Port write into a LogFile / TextFile?> > >> > > The output format is Prometheus but you don't need a prometheus server to get> > >> > > it.> > >> > > Once opened, you can simply fetch it like this:> > >> > > wget http://:/metrics -O /tmp/output.txt> > >> > > or> > >> > > curl http://:/metrics -o /tmp/output.txt> >> > I've only ever gotten an empty reply when trying to extract metrics> >> > and I still do on Tor 4.6.7. I have some vague memory of the metrics> >> > previously only being for hidden services.> >> > All the metrics mentioned in the overload guide[1] seem to be missing.> >> > Having a quick look at the Git repository, it seems that only> >> > 0.4.71-alpha and latest master contain the necessary changes for these> >> > metrics.> >> > Is my assumption correct or am I doing something wrong?>> Correct, relay metrics are only available on >= 0.4.7.1-alpha. Hopefully, we>> should have an 0.4.7 stable by end of year (or around that time).>> David>> ->> xX/GscsnOTkKMqPla5JDOc2EqZ3GG/imhQ7gx+DQhVE=>> tor-relays mailing list>> tor-relays@lists.torproject.org>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Overloaded state indicator on relay-search

2021-09-30 Thread Bleedangel Tor Admin
   But I’m WELL below the 3/4 rule ..MemTotal:   65777296 kBMemFree:    63088388 kBI actually have 95.9121031670259% FREE which means I’m only using around 4% of my ram!Am I understanding the 3/4 wrong? Thanks againSent from ProtonMail for iOS On Tue, Sep 28, 2021 at 21:50, Gary C. New <garyc...@yahoo.com> wrote:  
Bleedangel,You definitely have a nice rig with 12 CPUs and 64GB of RAM. I have a bunch of 2 CPU and 256MB rigs that I loadbalance as a single relay.Following David's explanation as to how the overloaded state is metered, I believe your issue is with RAM availability being over the 3/4 rule.MemTotal:   65777296 kBMemFree:    63088388 kBYou might try freeing up RAM resources (below the 3/4 limit) and confirm whether that resolves the issue, after 72 hours.Personally, I think a better approach would be to have the upstream relay monitor and report overloaded states, but I only know so much about Tor.Hope this helps.Respectfully,Gary





On Tuesday, September 28, 2021, 10:28:42 AM PDT, Bleedangel Tor Admin  wrote:



-BEGIN PGP SIGNED MESSAGE-Hash: SHA512I am having a lot of trouble figuring out why my relay keeps showing as overloaded on the search page. I believe I have more than enough memory and cpu power to not be overloaded on hardware. My server internet connection is 10GB up/down unmetered.I cannot for the life of me figure out why the relay search page continuously tells me i am overloaded. Can someone assist me in troubleshooting this?Thank you. Pertinent hardware information is pasted below:output of /proc/meminfo:--[ BEGIN PASTE ]--MemTotal:   65777296 kBMemFree:    63088388 kBMemAvailable:   63415088 kBBuffers:  180096 kBCached:   736396 kBSwapCached:    0 kBActive:   449428 kBInactive:    1729304 kBActive(anon):  14552 kBInactive(anon):  1292048 kBActive(file): 434876 kBInactive(file):   437256 kBUnevictable:   0 kBMlocked:   0 kBSwapTotal:  33520636 kBSwapFree:   33520636 kBDirty:   236 kBWriteback: 0 kBAnonPages:   1262300 kBMapped:   273164 kBShmem: 48592 kBKReclaimable:  94828 kBSlab: 204624 kBSReclaimable:  94828 kBSUnreclaim:   109796 kBKernelStack:    5040 kBPageTables: 9308 kBNFS_Unstable:  0 kBBounce:    0 kBWritebackTmp:  0 kBCommitLimit:    66409284 kBCommitted_AS:    2374432 kBVmallocTotal:   34359738367 kBVmallocUsed:   34348 kBVmallocChunk:  0 kBPercpu:    16384 kBHardwareCorrupted: 0 kBAnonHugePages: 0 kBShmemHugePages:    0 kBShmemPmdMapped:    0 kBFileHugePages: 0 kBFilePmdMapped: 0 kBCmaTotal:  0 kBCmaFree:   0 kBHugePages_Total:   0HugePages_Free:    0HugePages_Rsvd:    0HugePages_Surp:    0Hugepagesize:   2048 kBHugetlb:   0 kBDirectMap4k:  332988 kBDirectMap2M: 7981056 kBDirectMap1G:    58720256 kB--[ END PASTE ]--output of /proc/cpuinfo:--[ BEGIN PASTE ]--processor   : 0vendor_id   : AuthenticAMDcpu family  : 23model   : 113model name  : AMD Ryzen 5 3600 6-Core Processorstepping    : 0microcode   : 0x8701021cpu MHz : 2200.000cache size  : 512 KBphysical id : 0siblings    : 12core id : 0cpu cores   : 6apicid  : 0initial apicid  : 0fpu : yesfpu_exception   : yescpuid level : 16wp  : yesflags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca sme sev sev_esbugs    : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypassbogomips    : 7202.22TLB size    : 3072 4K pagesclflush size    : 64cache_alignment : 64address sizes   : 43 bits physical, 48 bits virtualpower management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]processor   : 1vendor_id   : AuthenticAMDcpu family  : 23model   : 113model name  : AMD Ryzen 5 3600 

Re: [tor-relays] Overloaded state indicator on relay-search

2021-09-28 Thread Bleedangel Tor Admin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I am having a lot of trouble figuring out why my relay keeps showing as 
overloaded on the search page. I believe I have more than enough memory and cpu 
power to not be overloaded on hardware. My server internet connection is 10GB 
up/down unmetered.

I cannot for the life of me figure out why the relay search page continuously 
tells me i am overloaded. 
Can someone assist me in troubleshooting this?

Thank you. Pertinent hardware information is pasted below:

output of /proc/meminfo:

--[ BEGIN PASTE ]--

MemTotal:   65777296 kB
MemFree:    63088388 kB
MemAvailable:   63415088 kB
Buffers:  180096 kB
Cached:   736396 kB
SwapCached:    0 kB
Active:   449428 kB
Inactive:    1729304 kB
Active(anon):  14552 kB
Inactive(anon):  1292048 kB
Active(file): 434876 kB
Inactive(file):   437256 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal:  33520636 kB
SwapFree:   33520636 kB
Dirty:   236 kB
Writeback: 0 kB
AnonPages:   1262300 kB
Mapped:   273164 kB
Shmem: 48592 kB
KReclaimable:  94828 kB
Slab: 204624 kB
SReclaimable:  94828 kB
SUnreclaim:   109796 kB
KernelStack:    5040 kB
PageTables: 9308 kB
NFS_Unstable:  0 kB
Bounce:    0 kB
WritebackTmp:  0 kB
CommitLimit:    66409284 kB
Committed_AS:    2374432 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   34348 kB
VmallocChunk:  0 kB
Percpu:    16384 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages:    0 kB
ShmemPmdMapped:    0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
CmaTotal:  0 kB
CmaFree:   0 kB
HugePages_Total:   0
HugePages_Free:    0
HugePages_Rsvd:    0
HugePages_Surp:    0
Hugepagesize:   2048 kB
Hugetlb:   0 kB
DirectMap4k:  332988 kB
DirectMap2M: 7981056 kB
DirectMap1G:    58720256 kB
--[ END PASTE ]--

output of /proc/cpuinfo:

--[ BEGIN PASTE ]--
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 23
model   : 113
model name  : AMD Ryzen 5 3600 6-Core Processor
stepping    : 0
microcode   : 0x8701021
cpu MHz : 2200.000
cache size  : 512 KB
physical id : 0
siblings    : 12
core id : 0
cpu cores   : 6
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 16
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf 
rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave 
avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 
3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext 
perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall 
fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni 
xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total 
cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock 
nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter 
pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov 
succor smca sme sev sev_es
bugs    : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips    : 7202.22
TLB size    : 3072 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 43 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 23
model   : 113
model name  : AMD Ryzen 5 3600 6-Core Processor
stepping    : 0
microcode   : 0x8701021
cpu MHz : 2200.000
cache size  : 512 KB
physical id : 0
siblings    : 12
core id : 1
cpu cores   : 6
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 16
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf 
rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave 
avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 
3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext 
perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall 
fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni 
xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total 
cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd 

Re: [tor-relays] Overloaded state indicator on relay-search

2021-09-27 Thread Bleedangel Tor Admin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Agreed, can the thresholds be published publicly for easy reference? Sometimes 
i get the overloaded flag but i have nothing in my logs, and my cpu/memory is 
abundant. 
It would be much easier to ascertain the cause of this if we knew what we were 
looking for!

Thank you

‐‐‐ Original Message ‐‐‐
On Monday, September 27th, 2021 at 10:23 AM, Gary C. New via tor-relays 
 wrote:

> George,
>
> The referenced support article provides recommendations as to what might be 
> causing the overloaded state, but it doesn't provide the metric(s) for how 
> Tor decides whether a relay is overloaded. I'm trying to ascertain the later.
>
> I would assume the overloaded state metric(S) is/are a maximum timeout value 
> and/or reoccurrence value, etc.
>
> By knowing what the overloaded state metric is, I can tune my Tor relay just 
> short of it.
>
> Thank you for your reply.
>
> Respectfully,
>
> Gary
>
> On Monday, September 27, 2021, 2:44:35 AM PDT, Georg Koppen 
>  wrote:
>
> Gary C. New via tor-relays:
>
> >  Hiro,
>
> > Presently, I'm seeing a similar issue. On my laptop, I'm observing an 
> > overloaded status for my relay. However, the same relay shows a green 
> > status on my phone.
>
> > Do you do any user-agent detection?
>
> > I'm still interested in those magic numbers, which determine whether a 
> > relay has reached an overloaded state.
>
> Which numbers do you mean? Is there anything missing from the support
>
> article[1] you feel should be there?
>
> Georg
>
> [1] https://support.torproject.org/relay-operators/relay-bridge-overloaded/
>
> > Thank You.
>
> > Respectfully,
>
> >
>
> > Gary
>
> >
>
> >    On Saturday, September 25, 2021, 7:11:31 AM PDT, Silvia/Hiro 
> > wrote: 
>
> > 
>
> >  Hi,
>
> > I went back in history and tried to find out whenever your node
>
> > FriendlyExit1 was overloaded. I couldn't find the exact descriptor.
>
> >
>
> > One thing I can think of is that on the 22nd when I deployed this I
>
> > noticed a few typos in the code and had to make a second release. Maybe
>
> > something was cached for a while and you what you were accessing from
>
> > mobile was the buggy page.
>
> >
>
> > If it happens again there are two buttons at the end of the page where
>
> > you can see the latest server and extra-info descriptors. If you
>
> > download the server one you would be able to verify that there is a
>
> > "overload-general" field in there. If there isn't we have a bug :).
>
> >
>
> > Please let me know if this happens again.
>
> >
>
> > Cheers,
>
> > -hiro
>
> >
>
> > On 9/24/21 2:39 PM, friendlyexitnode via tor-relays wrote:
>
> >> Hey hiro, thanks!
>
> >>
>
> >> I've also attached some screenshots too if it helps (sorry, I should have 
> >> done that before). I had first noticed this around 3:45 PM CST on 
> >> September 23.
>
> >>
>
> >> - The Friendly Exit Node Family
>
> >>
>
> >> Sent with ProtonMail Secure Email.
>
> >>
>
> >> ‐‐‐ Original Message ‐‐‐
>
> >>
>
> >> On Friday, September 24th, 2021 at 4:47 AM, Silvia/Hiro 
> >>  wrote:
>
> >>
>
> >>> On 9/23/21 10:54 PM, friendlyexitnode via tor-relays wrote:
>
> >>>
>
>  This looks like an awesome feature! I super appreciate it.
>
> 
>
>  Random question though (and I'm the first to admit I may be doing 
>  something wrong), I notice that on Mobile it says my relays are 
>  overloaded however when I view it on a normal computer I don't get the 
>  overloaded indicator. I've tried refreshing multiple times but getting 
>  the same results. Is anyone seeing the same thing?
>
> >>>
>
> >>> Hi,
>
> >>>
>
> >>> could you let me know when you accessed the page via mobile approximately?
>
> >>>
>
> >>> I'll try to check if any of your relays were overloaded in the past.
>
> >>>
>
> >>> When a node is overloaded the state is kept for 72 hours.
>
> >>>
>
> >>> Cheers,
>
> >>>
>
> >>> -hiro
>
> >>>
>
>  Family Members:
>
> 
>
>  F01E382DA524A57F2BFB3C4FF270A23D5CD3311D
>
> 
>
>  6231A1370700DD03046A85D953D35CAB5C21
>
> 
>
>  F9A28AB71D7E4E446308641A556EA53BA55FCB50
>
> 
>
>  23F74D581DE92AC59D3527DE4D448E036139D81E
>
> 
>
>  A00E900534DFF76371064C03714753EAF8B88820
>
> 
>
>  C232D8EE677E6BDF5CFFDDCAC4E2B1682DCE7AE5
>
> 
>
>  -  The Friendly Exit Node Family
>
> 
>
>  Sent with ProtonMail Secure Email.
>
> 
>
>  ‐‐‐ Original Message ‐‐‐
>
> 
>
>  On Thursday, September 23rd, 2021 at 8:39 AM, Silvia/Hiro 
>  h...@torproject.org wrote:
>
> 
>
> > Hello all,
>
> >
>
> > One of our goals with our current performance work is to reduce the
>
> >
>
> > overload of relays in the network. The implementation of proposal 328[1]
>
> >
>
> > a while back made different overload indicators available to relay
>
> >
>
> > operators and since a couple of weeks ago those can be tracked via
>
> >
>
> > Onionoo[2] as 

Re: [tor-relays] Overloaded state indicator on relay-search

2021-09-23 Thread Bleedangel Tor Admin
My relay was showing as overloaded and I couldn’t figure out why, system utilization was extremely low, only using a tiny bit of ram, network throughout was problem free, I was scratching my head until I realized it shows for 72 hours, and I had been doing a heavy distcc compile on my server one day previous.FYI all, if you show overloaded, it may not be tor, it may be that distcc compiling you did yesterday!On Thu, Sep 23, 2021 at 09:39, Silvia/Hiro  wrote:  Hello all,One of our goals with our current performance work is to reduce theoverload of relays in the network. The implementation of proposal 328[1]a while back made different overload indicators available to relayoperators and since a couple of weeks ago those can be tracked viaOnionoo[2] as well.As we know that a lot of our relay operators use relay search to checkfor the health of their relays, we have launched a new feature there,too, to help them know when their relays are overloaded.When a relay is in the overloaded state we show an amber dot next to therelay nickname.Currently we are counting between 50 and 80 overloaded relays andbetween 10 and 20 overloaded bridges.The overloaded state is reached when one or many of the possible loadmetrics have been triggered. When this happens we show it for 72 hoursafter the relay has recovered [3]. Note, though, that not all of theexposed overload metrics are triggering the overload indicator on relaysearch yet.If you noticed your relay is overloaded, please check the followingsupport article to find out how you can recover to a "normal" state:https://support.torproject.org/relay-operators/relay-bridge-overloaded/Let us known how you find this new feature.Cheers,-hiro[1]https://gitweb.torproject.org/torspec.git/tree/proposals/328-relay-overload-report.md[2]https://lists.torproject.org/pipermail/tor-project/2021-August/003168.html[3] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n637___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - tor@bleedangel.com - a010c89f.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


[tor-relays] Need help with Dir Address and Exit Address

2021-09-20 Thread Bleedangel Tor Admin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all

I have an exit relay running, and all is working well. I am a stickler though, 
and i notice when i search my relay on the metrics page, the following two 
items are listed as 'none':

Dir Address 
Exit Address

Can anyone help me to get these reporting properly? I have a V2 Directory flag 
and my dir port is 9030. I am allowing ipv4 exits.

Metric page for reference: 
https://metrics.torproject.org/rs.html#details/5161B1C501805A0D3E9F87AFCAC9CBC075DBE8DC

Thanks for any help you can give!
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wnUEARYKAAYFAmFJOgQAIQkQ07hp34FMyg4WIQSgEMifmnN5ohFWvfnTuGnf
gUzKDs8DAP4hSvlEPrlDkIY5vlLULhJHuNVbq/UT3r5mfBg/cg+p0wEAltfV
bPlU/3wfg7j0b31h6R4g+Ik+96fkoq9VTqiydQg=
=6AAW
-END PGP SIGNATURE-


publickey - tor@bleedangel.com - 0xA010C89F.asc
Description: application/pgp-keys


publickey - tor@bleedangel.com - 0xA010C89F.asc.sig
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays