Tor service keeps restarting on Raspbian

The Tor metrics
and my logs in /var/log/tor/notices.log show that TOR service keeps restarting. I can’t see a reason in the logs.

What’s also weird:

  • After the restart, the service seems to remembers the previous stats:
[...]
Feb 10 03:06:24.000 [notice] Heartbeat: Tor's uptime is 16:39 hours, with 289 circuits open. I've sent 13.09 GB and received 13.07 GB.  I've received 219726 connections on IPv4 and 0 on IPv6. I've made 19901 connections with IPv4 and 7012 with IPv6.
Feb 10 03:06:24.000 [notice] Heartbeat: Tor's uptime is 16:39 hours, with 289 circuits open. I've sent 13.09 GB and received 13.07 GB. I've received 219726 connections on IPv4 and 0 on IPv6. I've made 19901 connections with IPv4 and 7012 with IPv6.
Feb 10 03:06:24.000 [notice] While bootstrapping, fetched this many bytes: 1906674 (microdescriptor fetch)
Feb 10 03:06:24.000 [notice] While bootstrapping, fetched this many bytes: 1906674 (microdescriptor fetch)
Feb 10 03:06:24.000 [notice] While not bootstrapping, fetched this many bytes: 6224 (server descriptor upload); 2063690 (consensus network-status fetch); 35902 (authority cert fetch); 956038 (microdescriptor fetch)
Feb 10 03:06:24.000 [notice] While not bootstrapping, fetched this many bytes: 6224 (server descriptor upload); 2063690 (consensus network-status fetch); 35902 (authority cert fetch); 956038 (microdescriptor fetch)
Feb 10 03:06:24.000 [notice] Circuit handshake stats since last time: 12/12 TAP, 47051/47051 NTor.
Feb 10 03:06:24.000 [notice] Circuit handshake stats since last time: 12/12 TAP, 47051/47051 NTor.
Feb 10 03:06:24.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 282 v4 connections; initiated 25435 and received 218652 v5 connections.
Feb 10 03:06:24.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 282 v4 connections; initiated 25435 and received 218652 v5 connections.
Feb 10 03:06:24.000 [notice] DoS mitigation since startup: 2 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 525 INTRODUCE2 rejected.
Feb 10 03:06:24.000 [notice] DoS mitigation since startup: 2 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 525 INTRODUCE2 rejected.
Feb 10 03:23:12.000 [notice] Channel padding timeout scheduled 243926ms in the past. 
Feb 10 03:23:12.000 [notice] Channel padding timeout scheduled 243926ms in the past. 
Feb 10 03:23:12.000 [notice] Channel padding timeout scheduled 197992ms in the past. 
Feb 10 03:23:12.000 [notice] Channel padding timeout scheduled 197992ms in the past. 
[...]
Feb 10 06:04:25.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [18780 similar message(s) suppressed in last 60 seconds]
Feb 10 06:04:25.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [18780 similar message(s) suppressed in last 60 seconds]
Feb 10 06:06:26.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [3788 similar message(s) suppressed in last 180 seconds]
Feb 10 06:06:26.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [3788 similar message(s) suppressed in last 180 seconds]
Feb 10 06:23:03.000 [notice] External address seen and suggested by a directory authority: 93.104.160.217
Feb 10 06:23:03.000 [notice] External address seen and suggested by a directory authority: 93.104.160.217
Feb 10 06:24:03.000 [notice] Our IP Address has changed from 93.104.173.4 to 93.104.160.217; rebuilding descriptor (source: METHOD=NONE).
Feb 10 06:24:03.000 [notice] Our IP Address has changed from 93.104.173.4 to 93.104.160.217; rebuilding descriptor (source: METHOD=NONE).
Feb 10 06:40:50.000 [notice] Now checking whether IPv4 ORPort 93.104.160.217:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 10 06:40:50.000 [notice] Now checking whether IPv4 ORPort 93.104.160.217:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 10 06:40:50.000 [notice] Now checking whether IPv6 ORPort [2001:a61:35ba:9801:2d52:f76b:c68e:11b8]:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 10 06:40:50.000 [notice] Now checking whether IPv6 ORPort [2001:a61:35ba:9801:2d52:f76b:c68e:11b8]:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 10 06:40:58.000 [notice] Self-testing indicates your ORPort 93.104.160.217:9001 is reachable from the outside. Excellent.
Feb 10 06:40:58.000 [notice] Self-testing indicates your ORPort 93.104.160.217:9001 is reachable from the outside. Excellent.
Feb 10 06:41:04.000 [notice] Performing bandwidth self-test...done.
Feb 10 06:41:04.000 [notice] Performing bandwidth self-test...done.
Feb 10 06:44:03.000 [notice] Auto-discovered IPv6 address [2001:a61:35ba:9801:2d52:f76b:c68e:11b8]:9001 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 3420 seconds]
Feb 10 06:44:03.000 [notice] Auto-discovered IPv6 address [2001:a61:35ba:9801:2d52:f76b:c68e:11b8]:9001 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 3420 seconds]
Feb 10 07:44:03.000 [notice] Auto-discovered IPv6 address [2001:a61:35ba:9801:2d52:f76b:c68e:11b8]:9001 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds]
Feb 10 07:44:03.000 [notice] Auto-discovered IPv6 address [2001:a61:35ba:9801:2d52:f76b:c68e:11b8]:9001 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds]
Feb 10 08:30:52.000 [notice] Channel padding timeout scheduled 269834ms in the past. 
Feb 10 08:30:52.000 [notice] Channel padding timeout scheduled 269834ms in the past. 
Feb 10 08:30:52.000 [notice] Channel padding timeout scheduled 245251ms in the past. 
Feb 10 08:30:52.000 [notice] Channel padding timeout scheduled 245251ms in the past. 
Feb 10 08:44:03.000 [notice] Auto-discovered IPv6 address [2001:a61:35ba:9801:2d52:f76b:c68e:11b8]:9001 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds]
Feb 10 08:44:03.000 [notice] Auto-discovered IPv6 address [2001:a61:35ba:9801:2d52:f76b:c68e:11b8]:9001 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds]
Feb 10 08:58:14.000 [notice] Channel padding timeout scheduled 157984ms in the past. 
Feb 10 08:58:14.000 [notice] Channel padding timeout scheduled 157984ms in the past. 
Feb 10 08:58:14.000 [notice] Channel padding timeout scheduled 174011ms in the past. 
Feb 10 08:58:14.000 [notice] Channel padding timeout scheduled 174011ms in the past. 
[...]
Feb 10 09:06:24.000 [notice] Heartbeat: Tor's uptime is 2:42 hours, with 2451 circuits open. I've sent 13.83 GB and received 14.00 GB. I've received 236723 connections on IPv4 and 0 on IPv6. I've made 21224 connections with IPv4 and 7424 with IPv6.
[...]

And most messages in the log appear twice…i.e. exactly the same message.

As a new user I can’t upload the logfile, so I’ll provide excerpts.

Your relay is running 0.4.5.10 which is quite old. I remember reading that 0.4.5 support would end sometime soon’ish (March this year?).

Maybe consider upgrading to latest stable? Make a backup of your key files before doing so though.

1 Like

It’s the version provided by Raspbian Debian Bullseye via:

deb http://raspbian.raspberrypi.org/raspbian/ bullseye main contrib non-free rpi

I didn’t update the OS in a while, so I could move to “testing”/Bookworm.

Are there any instructions on how to do such an update properly (backup/restore key material…)?
edit: I found this (“upgrade or move”) and will do as suggested

I’m running Raspbian/Tor on an SD card with a tmpfs for /var/lib/tor and /var/log, so that the SD card isn’t destroyed due to too many writes (as it happened before).

I remember that the last time I’ve updated, the “ID”/keys of my tor instance were lost because I didn’t handle the files in /var/lib/tor correctly. And after starting new, tor created new keys/files, and I couldn’t recover the previous “identity”.

I’ll keep having a look at usage of memory and tmpfs filesystems.

Btw. I’m ignoring the messages

Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy.

I’ve once halved the values, but that didn’t change anything ecxept those messages did not show up.
And the Tor relay website just showed that the node was handling much more traffic.

Current setting:

MaxAdvertisedBandwidth 400 KB
RelayBandwidthRate 800 KB 
RelayBandwidthBurst 1600 KB

Are you running 32-bit Raspberry Pi OS?
Upgrade to 64-bit lite, then the latest Tor should work.

No, I’m using an older Raspberry Pi Model B Rev 2.
I’m going to update to the next Debian distro anyway, only need to reverse-engineer my configuration on the Raspberry to understand what’s happening…

I’m having a tmpfs on /var/lib/tor via /etc/fstab to have little writes on the SD card, and I’m mounting a partition of the SD card to /var/lib/tor/keys to have the keys persistent.

It seems with the last power cut/reboot, all this worked automatically, so I must somehow have it configured to be available in the correct order at startup…well, I forgot either that I did it manually or I forgot how I’ve configured it to work at startup :thinking:

Unfortunately, these instructions to use a tor repository for the latest stable tor releases are not applicable to my older Raspberry model (armhf).

At least I figured out how the /var/lib/tor/keys mountpoint is created and how the data partition is mounted there before startup of tor (a script is called via etc/rc.local…).

After upgrading to Raspbian bookworm, the relay has now been running for seven days w/o restarting. That’s longer than before at least, I’ll continue keeping track of it.

With the new Tor version 0.4.7.13 I get better reports on the overload (via metrics and the notices.log).

On a Raspberry with 512MB RAM, my settings are

MaxAdvertisedBandwidth 400 KB
RelayBandwidthRate 800 KB 
RelayBandwidthBurst 1600 KB

Tor is the only process using lots of RAM and CPU, but both resources are at max 20 - 50% usage by Tor (as per top).

Acc. to the support article for overloaded relays, connections have been dropped, though. I’ve tweaked the system a bit with the suggestions:

/etc/rc.local

sysctl -w net.ipv4.ip_local_port_range="15000 64000"
sysctl -w fs.file-max=100000
ulimit -n 10000

edit: why can’t I add hyperlinks to "support.torproject.org articles?`

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

After the tweaks the Tor relay is now running stable and without further overload since 21 days. I wonder why the concensus weight dropped to 130 and whether my relay wouldbe better off as a bridge due to the relay requirements.