counterweight
2a80f0e3ca
The RPC probe flapped while every other knots check stayed green. Each burst lined up with a block: validation on the saturated HDD holds the node busy while Fulcrum, mempool and DATUM all fetch the block, and bitcoind rejected calls with "work queue depth exceeded" (93 times on 2026-10-18). - 403: the probe runs every minute, so failure-threshold 4 rides out a 1-3 minute burst while a real outage still alerts within ~5 minutes. Probes now take an optional failure_threshold over a shared probe_alert. - rpcworkqueue=64 and rpcthreads=8, so bursts queue instead of failing. Profiling later showed the stalls are per-input UTXO lookups at ~5 ms each - HDD seek latency - so this treats the symptom. The fix is chainstate on SSD. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
69 lines
2.1 KiB
Django/Jinja
69 lines
2.1 KiB
Django/Jinja
# Bitcoin Knots Configuration
|
|
# Generated by Ansible
|
|
|
|
# Data directory (blockchain storage)
|
|
datadir={{ bitcoin_large_data_dir }}
|
|
|
|
# RPC Configuration
|
|
server=1
|
|
rpcuser={{ bitcoin_rpc_user }}
|
|
rpcpassword={{ bitcoin_rpc_password }}
|
|
rpcbind={{ bitcoin_rpc_bind }}
|
|
rpcport={{ bitcoin_rpc_port }}
|
|
rpcallowip=0.0.0.0/0
|
|
rpcworkqueue={{ bitcoin_rpcworkqueue }}
|
|
rpcthreads={{ bitcoin_rpcthreads }}
|
|
|
|
# Network Configuration
|
|
listen=1
|
|
port={{ bitcoin_p2p_port }}
|
|
maxconnections={{ bitcoin_max_connections }}
|
|
|
|
# Performance
|
|
dbcache={{ bitcoin_dbcache_mb }}
|
|
|
|
# Transaction Index (optional)
|
|
{% if bitcoin_enable_txindex %}
|
|
txindex=1
|
|
{% endif %}
|
|
|
|
{# The live node carries this comment and the template never produced it, so a
|
|
run would have silently deleted it. Harmless in itself, but matching it keeps
|
|
this task at `ok` - which means any future `changed` here is a real signal
|
|
rather than known noise. #}
|
|
# Pruning (optional)
|
|
|
|
# Logging
|
|
logtimestamps=1
|
|
{% if bitcoin_logfile %}
|
|
logfile={{ bitcoin_logfile }}
|
|
{% else %}
|
|
printtoconsole=1
|
|
{% endif %}
|
|
|
|
# ZMQ Configuration
|
|
{% if bitcoin_zmq_enabled | default(false) %}
|
|
zmqpubrawblock={{ bitcoin_zmq_bind }}:{{ bitcoin_zmq_port_rawblock }}
|
|
zmqpubrawtx={{ bitcoin_zmq_bind }}:{{ bitcoin_zmq_port_rawtx }}
|
|
zmqpubhashblock={{ bitcoin_zmq_bind }}:{{ bitcoin_zmq_port_hashblock }}
|
|
zmqpubhashtx={{ bitcoin_zmq_bind }}:{{ bitcoin_zmq_port_hashtx }}
|
|
{% endif %}
|
|
|
|
# Security
|
|
disablewallet=1
|
|
{% if bitcoin_datum_gateway_enabled %}
|
|
|
|
{# These were hand-added on the node and were NOT in this template, so running
|
|
the playbook would have stripped them. blocknotify is how datum_gateway
|
|
learns a new block landed; without it solo mining keeps grinding on a stale
|
|
template - a silent failure that costs money rather than raising an error.
|
|
Kept as a Jinja comment so the explanation stays in the repo and out of the
|
|
deployed config. #}
|
|
# Specific for DATUM gateway
|
|
blockmaxsize={{ bitcoin_blockmaxsize }}
|
|
blockmaxweight={{ bitcoin_blockmaxweight }}
|
|
blocknotify={{ bitcoin_blocknotify }}
|
|
maxmempool={{ bitcoin_maxmempool }}
|
|
blockreconstructionextratxn={{ bitcoin_blockreconstructionextratxn }}
|
|
|
|
{% endif %}
|