Bitcoin Node V28 not starting after update from V27

After Updating Bitcoin Core Node to version 28, Bitcoin node would not start (no data displayed on bitcoin node umbrel page).

I investigated bitcoin debug.log first with:
tail -n 1000 /mnt/data/umbrel/app-data/bitcoin/data/bitcoin/debug.log

The relevant lines in the log appear to be this:

[net:error] Unable to bind to 0.0.0.0:8333 on this computer. Bitcoin Core is probably already running.
2024-11-10T18:57:39Z [error] Unable to bind to 0.0.0.0:8333 on this computer. Bitcoin Core is probably already running.
2024-11-10T18:57:39Z [error] Failed to listen on any port. Use -listen=0 if you want this.
2024-11-10T18:57:39Z Shutdown: In progress...

Then it appears, bitcoin core will restart and go through the start-up cycle until it shuts down again with the above error.

I also noted in the github bitcoin core v28 release notices the following:


P2P and Network Changes

Previously if Bitcoin Core was listening for P2P connections, either using default settings or via bind=addr:port it would always also bind to 127.0.0.1:8334 to listen for Tor connections. It was not possible to switch this off, even if the node didn’t use Tor. This has been changed and now bind=addr:port results in binding on addr:port only. The default behavior of binding to 0.0.0.0:8333 and 127.0.0.1:8334 has not been changed.

If you are using a bind=… configuration without bind=…=onion and rely on the previous implied behavior to accept incoming Tor connections at 127.0.0.1:8334, you need to now make this explicit by using bind=… bind=127.0.0.1:8334=onion. (#22729)

Bitcoin Core will now fail to start up if any of its P2P binds fail, rather than the previous behaviour where it would only abort startup if all P2P binds had failed. (#22729)


This last sentence indicates different behavior in Version 28 which shuts down if it can’t bind to 0.0.0.0:8333 (i.e. can’t bind to “any of its P2P binds”).

How do I make sure nothing is already bound to port 8333?

How can i fix this with alterations to umbrel-bitcoin.conf ?

My umbrel-bitcoin.conf has these relevant lines already:

# Enable/disable incoming connections from peers.
listen=1
listenonion=0
i2pacceptincoming=0

[main]
bind=0.0.0.0:8333
bind=10.x.x.x:8334=onion

Just before the update on Version 27 of bitcoin core node, the node had no trouble running and binding to 8333.

Is the workaround below acceptable?

When I change in umbrel-bitcoin.conf from “bind=0.0.0.0:8333” to “bind=127.0.0.1:8333” bitcoind node comes back online (i.e. will not shut down due to failed binding error above) and appears to be working normally.
Have I lessened the nodes security by doing this?
Do I need bitcoind to bind to 0.0.0.0:8333 for other umbrel apps that make use of the node? Given the default setting of binding to 0.0.0.0:8333, not sure this is correct approach.

I was having a similar issue, your workaround worked for me. However, modifications to umbrel-bitcoin.conf get reverted after a app restart (at least for me), so would the fix would keep getting reverted. There is also a bitcoin.conf file in the same directory that references this file, I noticed that mine looked something like

# Load additional configuration file, relative to the data directory.
includeconf=umbrel-bitcoin.conf

...

bind=127.0.0.1:8333
bind=127.0.0.1:8334=onion

... 

What I think this means is that the bitcoin service would conflict with itself because the effective bitcoin config contains two bind lines (here and in the imported umbrel-bitcoin.conf) to the same address.

On a separate Umbrel instance with a fresh install I can see that bitcoin.conf is just

# Load additional configuration file, relative to the data directory.
includeconf=umbrel-bitcoin.conf

Modifying the one on my broken Umbrel instance to be the same as this fixes the issue for me.

I think in my case I think this was caused because I copied the blockchain from another non-Umbrel machine and I must have copied its bitcoin.config file also. I’m not sure how the includeconf line got in there if that’s the case as it’s Umbrel specific. However, I suspect an update modified this file rather than overwriting it.