Tor service keeps rebooting

I’ve installed StartOS on as a VM in my TrueNAS scale machine. It was syncing the blockchain up to about 30%, when it suddenly stopped making progress. I tried many things to debug, and eventually deleted the OS and reinstalled from scratch, since it worked the first time. I continued to get the same behavior in the Tor logs, with the service getting to 5%, receiving some sort of interrupt, and restarting. I’ve spent hours on google to no avail. Since the configuration is relatively locked down, I’m wondering if I’ve hit on some corner case? Or is my ISP being naughty? Tor Browser seems to work fine on my PC.


systemd[1]: Starting tor@default.service - Anonymizing overlay network for TCP...
tor[10316]: Jul 11 23:53:52.359 [notice] Tor 0.4.7.13 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.>
tor[10316]: Jul 11 23:53:52.359 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https:/>
tor[10316]: Jul 11 23:53:52.359 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
tor[10316]: Jul 11 23:53:52.359 [notice] Read configuration file "/etc/tor/torrc".
tor[10316]: Configuration was valid
tor[10317]: Jul 11 23:53:52.438 [notice] Tor 0.4.7.13 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.>
tor[10317]: Jul 11 23:53:52.438 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https:/>
tor[10317]: Jul 11 23:53:52.438 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
tor[10317]: Jul 11 23:53:52.438 [notice] Read configuration file "/etc/tor/torrc".
tor[10317]: Jul 11 23:53:52.439 [warn] You specified a public address '0.0.0.0:9050' for SocksPort. Other people>
tor[10317]: Jul 11 23:53:52.439 [notice] Opening Socks listener on 0.0.0.0:9050
tor[10317]: Jul 11 23:53:52.439 [notice] Opened Socks listener connection (ready) on 0.0.0.0:9050
tor[10317]: Jul 11 23:53:52.439 [notice] Opening Control listener on 127.0.0.1:9051
tor[10317]: Jul 11 23:53:52.439 [notice] Opened Control listener connection (ready) on 127.0.0.1:9051
Tor[10317]: We compiled with OpenSSL 101010ef: OpenSSL 1.1.1n  15 Mar 2022 and we are running with OpenSSL 10101>
Tor[10317]: Tor 0.4.7.13 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.>
Tor[10317]: Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/s>
Tor[10317]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Tor[10317]: Read configuration file "/etc/tor/torrc".
Tor[10317]: You specified a public address '0.0.0.0:9050' for SocksPort. Other people on the Internet might find>
Tor[10317]: Opening Socks listener on 0.0.0.0:9050
Tor[10317]: Opened Socks listener connection (ready) on 0.0.0.0:9050
Tor[10317]: Opening Control listener on 127.0.0.1:9051
Tor[10317]: Opened Control listener connection (ready) on 127.0.0.1:9051
Tor[10317]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Tor[10317]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Tor[10317]: Bootstrapped 0% (starting): Starting
systemd[1]: Started tor@default.service - Anonymizing overlay network for TCP.
Tor[10317]: Starting with guard context "default"
Tor[10317]: Signaled readiness to systemd\
Tor[10317]: New control connection opened from 127.0.0.1.
Tor[10317]: Opening Control listener on /run/tor/control
Tor[10317]: Opened Control listener connection (ready) on /run/tor/control
Tor[10317]: Bootstrapped 5% (conn): Connecting to a relay
Tor[10317]: Interrupt: exiting cleanly.
systemd[1]: Stopping tor@default.service - Anonymizing overlay network for TCP...
systemd[1]: tor@default.service: Deactivated successfully.
systemd[1]: Stopped tor@default.service - Anonymizing overlay network for TCP.
systemd[1]: Starting tor@default.service - Anonymizing overlay network for TCP...

Also some system logs might give a hint:

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SPANTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  0: embassy::net::tor::torctl
  at src/net/tor.rs:255
 Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
 Run with RUST_BACKTRACE=full to include source snippets., kind: Tor, revision: None }
 2023-07-12T07:47:36.331770Z INFO torctl: embassy::net::tor: Tor is started
 2023-07-12T07:48:07.381667Z ERROR embassy::net::tor: Tor Daemon Error: Tor stuck bootstrapping at 5%: Restarting tor
 2023-07-12T07:48:07.381695Z DEBUG embassy::net::tor: Error { source:
  0: Tor stuck bootstrapping at 5%
 Location:
  src/net/tor.rs:359
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SPANTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

It definitely looks like you’ve hit an edge-case, but we have one other recent report of this type of issue. Let me escalate this and see what we can find. In the meantime, can you please provide the following:

StartOS version
Bitcoin verision
Hardware with TrueNAS, or at least resources available to StartOS

You can also try the following - under System → Experimental Features → Reset Tor, there are options to restart Tor, as well as restarting and wiping state. The latter would give you fresh guard nodes.

I think I’ve found the issue, which is actually on the networking side. My server is far from my router, so I was using a wifi extender with an ethernet port. This worked just fine with a single host attached (the TrueNAS server), but once it got a second IP address and MAC on the same port, the link got really flaky for both hosts. Somebody’s ARP table was getting really confused, I think.

So, I don’t think the issue is on the startOS side, other than that the error messages are not very helpful when trying to chase down the root cause.

1 Like

Okay, good to know, thank you for the update. In regard to messaging, can you give an example of a better error message that you would like to have received? I think we take most of our logging directly from the tor daemon itself.

Honestly, I don’t know enough about Tor to know what would be considered a helpful indicator. But since it is hard to test and manipulate network settings, it took me a long time to figure out that I couldn’t even ping the default gateway from the server. I was getting a DHCP address with default GW and DNS server, and I could access via HTTP over the LAN, but after that nothing worked. It was very hard to troubleshoot.

Maybe include more information on System → Insights → About? In addition to the IPv4 / IPv6 address maybe have a submenu for an ipconfig/all output?

So I thought about this some more. Is there some way to test and confirm there is internet access, then show it in the GUI or logs? My issue was that even though the network was up and I could access the server from the LAN, there wasn’t connectivity to the internet.

We could potentially extend the Connection Status bar with some sort of Internet information, but it is a feature, not a bug, for the server to operate without Internet. Your information is always available on the LAN. If you have no internet connectivity at all, your Tor logs will show that you are not able to connect to the network - you can use this for now as an Internet indicator.

Hi, read this and thought I should also chip in, I am facing exactly similar problem too in my DIY setup using a Dell Optiplex 3050, running on latest StartOS, trying to sync up BTC node, but Tor seems to connect/disconnect…with src/net/ror.rs:359 error of Tor stuck bootstrapping at 95%. Tried the experimental Tor reboot function still didnt resolve.

Have you also tried a total reboot of the system? Remove power if necessary to be sure you are rebooting.