No outgoing connections

[BlackHatCoiner]

I had a power outage which shut down my RPi 4 abruptly. For the past two days I get no connections at all which has left me with an older state of the block chain. What happened and how can I fix this?

Bitcoin Core v0.21.1 with onlynet=onion, listenonion=1 and blocksonly=0. I can provide more info from the config file if it's necessary.

[vv181]

Have you tried to restart the Tor service, and it still got no connection? If that so, I would try to check the Tor service journal, see if the issues are there.

[DaveF]

If it was working I would 1st do as vv181 suggests.
Do you have anything else running on the RPi behind tor that you could come into the unit with from the outside to see if it's working?
Also, did you do another full shutdown / reboot. I have had some things get funky with a power-loss and not restart properly but a reboot fixes it.

-Dave

[BlackHatCoiner]

Have you tried to restart the Tor service, and it still got no connection? If that so, I would try to check the Tor service journal, see if the issues are there.

I have restarted Tor and it continues showing me the exact thing. I closed qt and ran bitcoind, and this is what's shown repeatedly after a little bit:

Code:

2021-12-27T15:15:53Z connect() to 127.0.0.1:9050 failed after select(): Connection refused (111)

Doesn't Tor use the same port? When I check the Tor service journal this is what comes up:

Code:

bitcoin@raspibolt:~ $ sudo journalctl -f -u tor
-- Logs begin at Fri 2021-12-24 11:17:01 GMT. --
Dec 24 11:58:25 raspibolt systemd[1]: Starting Anonymizing overlay network for TCP (multi-instance-master)...
Dec 24 11:58:25 raspibolt systemd[1]: Started Anonymizing overlay network for TCP (multi-instance-master).
Dec 27 15:08:00 raspibolt systemd[1]: Reloading Anonymizing overlay network for TCP (multi-instance-master).
Dec 27 15:08:00 raspibolt systemd[1]: Reloaded Anonymizing overlay network for TCP (multi-instance-master).

Do you have anything else running on the RPi behind tor that you could come into the unit with from the outside to see if it's working?

I think Apache, but it shouldn't open on startup.

Also, did you do another full shutdown / reboot. I have had some things get funky with a power-loss and not restart properly but a reboot fixes it.

So, what you're saying is to restart the RPi properly? Alright, just did.

I run bitcoind:

Code:

bitcoin@raspibolt:~ $ bitcoind
Error: Cannot obtain a lock on data directory /home/bitcoin/.bitcoin. Bitcoin Core is probably already running.

Then, bitcoin-cli stop to use the qt:

Code:

bitcoin@raspibolt:~ $ bitcoin-cli stop
error code: -28
error message:
Verifying blocks...

I went to protocol.h to check what does that mean. Apparently, the client is still... “warming up”. What is that suppose to mean?

[NeuroticFish]

Then, bitcoin-cli stop to use the qt:

Code:

bitcoin@raspibolt:~ $ bitcoin-cli stop
error code: -28
error message:
Verifying blocks...

I went to protocol.h to check what does that mean. Apparently, the client is still... “warming up”. What is that suppose to mean?

The "Verifying blocks..." is one of the things done at startup. It should not take too long... unless something is wrong.
It never happened to me, but this can be a start: https://bitcointalk.org/index.php?topic=622937.msg6902445#msg6902445
Is everything OK with the storage/SSD?

[BlackHatCoiner]

The verifying blocks finished and I did stop Bitcoin Core (and restarted it). The following continues existing and I don't get any outgoing connections;

Code:

2021-12-27T15:15:53Z connect() to 127.0.0.1:9050 failed after select(): Connection refused (111)

[vv181]

Tor use the same port?

Yep, 9050 is the default Tor socks proxy.

And IIRC the default Tor service unit that Debian uses is tor@default.service not tor. So try to post the output of:

Code:

sudo systemctl status tor@default.service

And also I believe the Bitcoin Tor documentation gives some useful information for debugging:

There are several ways to see your local onion address in Bitcoin Core:

    in the debug log (grep for "tor:" or "AddLocal")
    in the output of RPC getnetworkinfo in the "localaddresses" section
    in the output of the CLI -netinfo peer connections dashboard

You may set the -debug=tor config logging option to have additional information in the debug log about your Tor configuration.

CLI -addrinfo returns the number of addresses known to your node per network. This can be useful to see how many onion peers your node knows, e.g. for -onlynet=onion.

So, if you also post the output of the above I think it would be also useful to debug where the problem is.

[BlackHatCoiner]

So try to post the output of:

Code:

sudo systemctl status tor@default.service

Interesting... This is what I get:

Code:

bitcoin@raspibolt:~ $ sudo systemctl status tor@default.service
● tor@default.service - Anonymizing overlay network for TCP
   Loaded: loaded (/lib/systemd/system/tor@default.service; enabled-runtime; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2021-12-27 15:17:19 GMT; 57min ago
  Process: 722 ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /run/tor (code=exited, status=0/SUCCESS)
  Process: 723 ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config (code=e
  Process: 724 ExecStart=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 (code=exited, status=1/FAI
 Main PID: 724 (code=exited, status=1/FAILURE)

Dec 27 15:17:19 raspibolt systemd[1]: tor@default.service: Failed with result 'exit-code'.
Dec 27 15:17:19 raspibolt systemd[1]: Failed to start Anonymizing overlay network for TCP.
Dec 27 15:17:19 raspibolt systemd[1]: tor@default.service: Service RestartSec=100ms expired, scheduling restart.
Dec 27 15:17:19 raspibolt systemd[1]: tor@default.service: Scheduled restart job, restart counter is at 5.
Dec 27 15:17:19 raspibolt systemd[1]: Stopped Anonymizing overlay network for TCP.
Dec 27 15:17:19 raspibolt systemd[1]: tor@default.service: Start request repeated too quickly.
Dec 27 15:17:19 raspibolt systemd[1]: tor@default.service: Failed with result 'exit-code'.
Dec 27 15:17:19 raspibolt systemd[1]: Failed to start Anonymizing overlay network for TCP.

[vv181]

~

Status=1/failure should indicate some things. But I think further log is needed, please do $ journalctl -xe | tor

Code:

bitcoin@raspibolt:~ $ sudo journalctl -xe | tor
Dec 27 17:08:35.164 [notice] Tor 0.3.5.15 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Dec 27 17:08:35.164 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 27 17:08:35.164 [notice] Read configuration file "/etc/tor/torrc".
Dec 27 17:08:35.169 [warn] Directory /var/lib/tor/hidden_service_electrs/ cannot be read: Permission denied
Dec 27 17:08:35.170 [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.
Dec 27 17:08:35.170 [err] Reading config failed--see warnings above.

Seems the permission denied errorwarning is expected and does not indicate the issues. One more thing I would try to check is:

Code:

cat /var/log/syslog | grep tor

[BlackHatCoiner]

Code:

bitcoin@raspibolt:~ $ sudo journalctl -xe | tor
Dec 27 17:08:35.164 [notice] Tor 0.3.5.15 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Dec 27 17:08:35.164 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 27 17:08:35.164 [notice] Read configuration file "/etc/tor/torrc".
Dec 27 17:08:35.169 [warn] Directory /var/lib/tor/hidden_service_electrs/ cannot be read: Permission denied
Dec 27 17:08:35.170 [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.
Dec 27 17:08:35.170 [err] Reading config failed--see warnings above.

Reposted for notification:

Seems the permission denied errorwarning is expected and does not indicate the issues. One more thing I would try to check is:

Code:

cat /var/log/syslog | grep tor

Code:

bitcoin@raspibolt:~ $ sudo cat /var/log/syslog | grep tor
Dec 27 06:46:24 raspibolt systemd[1]: Starting User Runtime Directory /run/user/1002...
Dec 27 06:46:24 raspibolt systemd[1]: Started User Runtime Directory /run/user/1002.
Binary file (standard input) matches

[ABCbits]

Seems the permission denied errorwarning is expected and does not indicate the issues. One more thing I would try to check is:

Code:

cat /var/log/syslog | grep tor

Don't forget grep is case sensitive, so it should be Tor (not tor).

Code:

# -b -0 indicate current boot 
sudo journalctl -x -b -0 | grep Tor

Code:

sudo cat /var/log/syslog | grep Tor

[BlackHatCoiner]

[...]

https://pastebin.com/raw/ikHmkjzL

[vv181]

@BlackHatCoiner I actually have no idea what causes it, but looking at your last log, I think it seemed like the tor is already running even though the systemctl status isn't showing so.

I think you should try to run:

Code:

sudo netstat -plnt | grep 9051

to check whether port 9051 is indeed used by the Tor or not. If it has an output which I think it's likely, the last word of the output will show the application whose using the port. e.g., <pid>/app-name

After that, I think the only manual solution I could think of is to manually kill the Tor process and then try to restart the Tor service again.

Code:

sudo killall tor
sudo systemctl restart tor@default.service

and then check again if the tor is running properly using:

Code:

sudo systemctl status tor@default.service

Other than that, I have no idea where's the problem.

[NotATether]

Have you tried to restart the Tor service, and it still got no connection? If that so, I would try to check the Tor service journal, see if the issues are there.

I have restarted Tor and it continues showing me the exact thing. I closed qt and ran bitcoind, and this is what's shown repeatedly after a little bit:

Code:

2021-12-27T15:15:53Z connect() to 127.0.0.1:9050 failed after select(): Connection refused (111)

Connection refused means that nothing's listening on port 9050 on the localhost interface (check your Tor logs again). If the error was "host unreachable" or something like that, then it would mean your firewall is blocking the connection but since there is no such message, that is not the reason.

Code:

Dec 27 17:08:35.169 [warn] Directory /var/lib/tor/hidden_service_electrs/ cannot be read: Permission denied
Dec 27 17:08:35.170 [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.

Your hidden_service_electrs folder can't be read by the Tor service, if I remember correctly Tor is running as a different user and group than root, so changing the owner from "root" to "tor-user" or something like that should resolve the problem.