Public Pool ESOCKETTIMEDOUT on getmininginfo
Public Pool's NestJS backend cannot reach Bitcoin Core RPC: getmininginfo Error: ESOCKETTIMEDOUT — TCP socket times out before bitcoind responds. No template = no work = no shares.
Warning — Should be addressed soon
Symptoms
- Public Pool dashboard at `http://<node-ip>:2019` loads but shows no current block height, no template, no blocks-found counter
- Container logs repeat `Error getmininginfo Error: ESOCKETTIMEDOUT` every 1-5 seconds
- Bitaxe / NerdAxe / NerdQAxe shows `Pool: Connected` but submitted-shares counter never increments past zero
- `mining.notify` arrives once on connect, then no further work — miner sits hashing the same job ID forever
- `bitcoin-cli getmininginfo` from the same host as `bitcoind` returns clean JSON instantly, but Public Pool still times out
- `bitcoin-cli getblockchaininfo` shows `initialblockdownload: true` or `verificationprogress < 0.999`
- Umbrel: `sudo docker ps | grep bitcoin` shows the container Up but in `Restarting` cycle
- Public Pool app status green in UI, but logs internally show repeated RPC timeouts
- Tor-only node: Public Pool's RPC URL points at a clearnet `bitcoind` interface that isn't enabled
- Started failing immediately after an Umbrel (`0.5.x → 1.x → 1.4.x`) or Start9 upgrade
- Disk usage on the node host is >95% (full disk slows `bitcoind` RPC enough to trigger Public Pool's 30 s timeout)
- CPU load average sustained >`8.0` on a 4-core box (overloaded host = slow RPC = timeout)
- `curl` to `http://<node-ip>:8332/` from the Public Pool container hangs without response
Step-by-Step Fix
Restart Bitcoin Core from the node-host UI. Umbrel: App Store → Bitcoin Node → Restart. Start9: Services → Bitcoin Core → Restart. Wait 5 minutes for full mempool reindex and RPC handler reinit. This clears wedged RPC threads and triggers a clean handshake the next time Public Pool calls `getmininginfo`. Don't restart Public Pool yet — sequence matters.
Restart Public Pool from the node-host UI **after** Bitcoin Core is fully back up, not at the same time. Sequencing matters because of the Public Pool client retry latch (root cause bucket 7). Wait 90 seconds, then check the logs: you should see `Listening on stratum :2018` followed by `Connected to bitcoind RPC` and template-fetch lines like `Got block template at height NNNNN`.
Check the Bitcoin Node sync status in the host UI. Confirm 'Synced' with current block height matching `https://mempool.space/`. If it shows 'Syncing' or a block height behind, Public Pool will not work until sync completes — there is no setting to bypass this. Estimate 1-7 days IBD on consumer SSD, faster on NVMe.
Confirm Public Pool app version is current. App Store → Public Pool → check version vs https://github.com/benjamin-wilson/public-pool/releases. If you're more than two minor versions behind, update first — several RPC-retry fixes have shipped. Read the changelog before pulling latest.
SSH into the node host. Umbrel: `ssh umbrel@<node-ip>` (default password `moneyprintergobrrr` unless you changed it — change it). Start9: developer SSH if enabled. Bare Docker: your normal SSH user. Confirm you have `sudo`. From here on you're in shell territory and edits are at your own risk.
Verify `bitcoind` is reachable from the host: `bitcoin-cli getblockchaininfo`. If not in `$PATH`, run `sudo docker exec -it $(sudo docker ps -q --filter name=bitcoin) bitcoin-cli getblockchaininfo`. Confirm `initialblockdownload: false` and `verificationprogress` ≥ `0.99999`. If still in IBD: wait. There is no fix until IBD completes.
Locate `bitcoin.conf`. Umbrel: `~/umbrel/app-data/bitcoin/data/bitcoin/bitcoin.conf`. Start9: `/embassy-data/package-data/volumes/bitcoind/data/main/bitcoin.conf` (path varies by version). Bare Docker: wherever you mounted `/root/.bitcoin/`. Open with `nano` or `vi`. Make a backup before edits: `cp bitcoin.conf bitcoin.conf.bak`.
Confirm `rpcbind=0.0.0.0`, at least one `rpcallowip=` line covering Public Pool's container subnet (e.g. `rpcallowip=10.21.21.0/24` for Umbrel, `rpcallowip=172.16.0.0/12` for bare Docker bridges), and matching `rpcuser`/`rpcpassword` (or `rpcauth=`) credentials. **Always pair `rpcbind=0.0.0.0` with restrictive `rpcallowip` — never expose RPC to the internet.** Save and `sudo docker restart` the `bitcoind` container.
Pull Public Pool's RPC env. Umbrel: `cat ~/umbrel/app-data/public-pool/.env` (filename may differ; check the directory). Confirm `BITCOIN_RPC_USER`, `BITCOIN_RPC_PASSWORD`, `BITCOIN_RPC_HOST`, `BITCOIN_RPC_PORT` match `bitcoin.conf`. Common bug: Umbrel's templated env was generated against an old `rpcauth` and reinstalling `bitcoind` rotated the password. Edit the env to match, restart Public Pool.
Test RPC from inside the Public Pool container: `sudo docker exec -it $(sudo docker ps -q --filter name=public-pool) sh`, then `curl --user user:pass --data-binary '{"jsonrpc":"1.0","id":"t","method":"getmininginfo","params":[]}' -H 'content-type: text/plain;' http://<bitcoind-ip>:8332/`. If it succeeds, Public Pool config is correct — restart Public Pool one more time to clear stale state. If it fails, you have a network-isolation problem; go to Tier 3.
Confirm Docker network membership: `sudo docker network ls` then `sudo docker network inspect <network-name>`. Both `bitcoind` and `public-pool` containers must be on the same Docker network — typically `bitcoin_default` on Umbrel, or a user-defined bridge on bare Docker. If they aren't, attach Public Pool: `sudo docker network connect bitcoin_default <public-pool-container-id>`. Restart.
Bypass `node-bitcoin-core` retry quirks. If `bitcoind` is healthy and `curl` from inside the Public Pool container works, but the app still times out, the JS RPC client is in a wedged retry state. Stop and start (not restart): `sudo docker stop <public-pool-container>` then `sudo docker start <public-pool-container>`. The full lifecycle reset clears any latched timeout state inside the Node.js process.
Tune `bitcoind` RPC concurrency. Add to `bitcoin.conf`: `rpcthreads=16` (default 4) and `rpcworkqueue=64` (default 16). On a host running `bitcoind` + Public Pool + Lightning + electrs, the default 4 RPC threads exhaust easily. Restart `bitcoind`. This single change resolves a meaningful percentage of intermittent `ESOCKETTIMEDOUT` cases.
Run a packet capture for last-resort diagnosis: `sudo tcpdump -i any -nn -w /tmp/pp.pcap 'tcp port 8332'` for 60 seconds while Public Pool retries. Open in Wireshark. Confirm full TCP handshake, HTTP POST sent. No response = bitcoind issue. TCP RST = firewall issue. Response after 30 s = overload. Anything else = file at https://github.com/benjamin-wilson/public-pool/issues with the pcap attached.
Migrate to higher-spec hardware if you're on Pi 4 4GB or weaker. Bitcoin Core + Public Pool + Lightning is at the edge of what's feasible. Move to Pi 5 8GB minimum, or x86 mini-PC with NVMe. RPC timeout at the 30-second mark is often a hardware-saturation symptom, not a config bug. Budget $240-$1,200 CAD depending on platform.
Self-host Public Pool from source for full control. Clone https://github.com/benjamin-wilson/public-pool, build with documented Node.js + npm steps, point at any Bitcoin Core node you control, run under `systemd` or a process manager you trust. You skip Umbrel/Start9 app-framework abstractions — and their bugs. The Mining Hacker option for operators who want full control of the pool stack.
Run an alternative solo backend. CKPool (https://bitbucket.org/ckolivas/ckpool/) is the reference open-source solo pool, written in C, used by `solo.ckpool.org`. Smaller ops surface than Public Pool's NestJS stack, no JS RPC client quirks, battle-tested record. Setup is more involved, but for serious solo operations CKPool is the more durable choice. Public Pool wins on UI; CKPool wins on uptime.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.