[tor-relays] Help with FreeBSD relays

[Fabian Keil]

Scott Bennett <bennett at sdf.org> wrote on 2021-03-30:

> Fabian Keil <freebsd-listen at fabiankeil.de> wrote:
> 
> > xplato <xplato at protonmail.com> wrote on 2021-03-30:
> >
> > > I am a bit of a noob here so please bear with me. I ran a relay using
> > > Ubuntu with very few issues however I decide to add an additional
> > > relay and decided to use FreeBSD. They will only run for around 18
> > > hours and then they shut down. I have adjust the torrc file every
> > > way I know how and increased the Max vnodes thinking this may have
> > > been my issue. I can post the sysrc and torrc if needed. Anyone that
> > > might help me figure this out I would be grateful otherwise I am
> > > going to reluctantly move them both back to Ubuntu.
> >
> > What do you mean by "they" and "shutting down"?
> 
>      It exits on signal 6.  See the tail end of the log excerpt I
> included in my posting about 0.4.6.1-alpha being very noisy.  N.B.
> 0.4.5.7 also has the same bug.

It's not obvious to me that you are experiencing the same issue.

I have several non-exit relays running 0.4.5.7 on ElectroBSD systems
based on FreeBSD 11.4-STABLE and they appear to be stable.

One example:

Mar 30 08:50:48.691 [notice] {HEARTBEAT} Heartbeat: Tor's uptime is 13 days 0:00 hours, with 14270 circuits open. I've sent 11283.88 GB and received 11200.63 GB. I've received 3494368 connections on IPv4 and 0 on IPv6. I've made 653389 connections with IPv4 and 0 with IPv6.

While I'm also seeing BUG messages they are different from
yours and are probably related to the MaxMemInQueues settings:

Mar 30 07:10:01.071 [notice] {CONTROL} New control connection opened from 127.0.1.5.
Mar 30 07:10:09.457 [notice] {GENERAL} We're low on memory (cell queues total alloc: 952512 buffer total alloc: 2557952, tor compress total alloc: 292862049 (zlib: 0, zstd: 0, lzma: 292862001), rendezvous cache total alloc: 23736810). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
Mar 30 07:10:09.531 [notice] {GENERAL} Removed 1147072 bytes by killing 17401 circuits; 0 circuits remain alive. Also killed 2 non-linked directory connections.
Mar 30 07:10:09.532 [warn] {BUG} channel_flush_from_first_active_circuit: Bug: Found a supposedly active circuit with no cells to 
[...]
Mar 30 07:10:09.532 [warn] {BUG} channel_flush_from_first_active_circuit: Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.5.7 )

I intentionally reduced the MaxMemInQueues value before the upgrade
as the server became unresponsive due to a lack of mbuf clusters.

I wrote about it here:
https://www.fabiankeil.de/blog-surrogat/2021/03/14/website-ausfall-durch-mbuf-cluster-limit.html
(The text is in German but the Munin graphs and the log messages aren't).

I'm using Tor 0.4.6.1 alpha as a client and on a couple of servers
to provide onion services and haven't seen any crashes there either.

> > Please also check the system and tor logs to see if there are
> > any relevant log messages.
> 
>      I posted such in my previous two postings.

Again, I think it's premature to conclude that you are experiencing
the same issue.

> > If you don't already, you may want to start monitoring tor's
> > and the system's resource usage.
> >
>      xplato's relay may differ from mine, but mine isn't using much these
> days because the authorities have a) stopped giving mine an HSDir flag
> for the last two months or so after giving it seemingly randomly for
> months before that, and b) been giving or withholding a Fast flag
> seemingly also at random.  This is on a relay that often runs at 300
> KB/s to 400+ KB/s, both in and out.  The whole mess makes me wonder
> whether it's worth my bothering to maintain and run a relay anymore.
>      Can you tell us why the consensus documents on Sunday showed *all*
> authorities with Bandwidth=20 Unmeasured=1 for some hours?  What caused
> such an alarming situation?

I haven't looked at the consensus documents from Sunday and don't
run bandwidth scanners so I have no information on this.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20210330/3cdf9958/attachment.sig>