Avoid conflict with lamassu-server which also defaults to port 3000.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Let A be a service that depends on another service B.
When A can gracefully handle failures and restarts of B, use
```
wants = [ "B.service" ];
after = [ "B.service" ];
```
instead of
```
requires = [ "B.service" ];
after = [ "B.service" ];
```
in the definition of A.
This way, A keeps running when B is stopped or restarted after a failure.
With `requires`, A is instead stopped when B is stopped or restarted due to a failure.
This brings two benefits:
1. Improved uptime
Examples:
- RTL keeps running when one lightning node has failed
- btcpayserver keeps running and accepting on-chain payments when the lightning node has crashed
2. Avoids a systemd bug where depending units (`A.service` in the
above example) are not restarted when their dependency fails
(issue github/systemd#18856, no full link to avoid spamming the issue).
In real world nix-bitcoin deployments, this issue was only likely to
appear when clightning failed during activation, causing depending
units (like `RTL`) to stop and not be restarted.
All services depending on `clightning` have now been changed to use
`wants`, thereby avoiding the bug.
Services `electrs` and `lightning-loop` fail when their respective
dependencies stop, so these services have not been changed.
I also haven't changed services `joinmarket` and
`joinmarket-yieldgenerator`. Further manual testing is needed to
determine if they can be switched to `wants`.
Now all services that access secrets only run after the secrets setup
has finished.
Previously, we assumed that the systemd `after` dependency is
transitive, i.e. that adding an `after = [ "bitcoind.service" ]`
to a service implicitly pulled in the `after` dependency to
`nix-bitcoin-secrets.target` (which is defined for `bitcoind`).
This is not the case. Services could start before secrets setup
had finished, leading to service failure.
Previously, when merging different definitions of `extraConfig`,
only the top-level attrset was merged.
Example:
The two separate settings
nodes.lnd.extraConfig.Settings.userPersona = "MERCHANT";
nodes.lnd.extraConfig.Settings.logLevel = "DEBUG";
were previously merged into
nodes.lnd.extraConfig.Settings = { logLevel = "DEBUG" };
(The last definition has precedence.)
- Move option `rtl.nodes.{lnd,clightning}` -> `rtl.nodes.{lnd,clightning}.enable`
This is required by the next commit.
- Move option `rtl.loop` -> `rtl.nodes.lnd.loop`
- Only enable loop when `nodes.lnd` is enabled
This makes our list definitions mergeable with custom list values
set by users.
Previously, a module error ("value is a string while a list
was expected") was thrown instead.
This commit was partly auto-generated with this script:
#!/usr/bin/env ruby
Dir["**/*.nix"].each do |file|
src = File.read(file)
fixed = src.gsub(/ReadWritePaths *= *(.*?);/) do
"ReadWritePaths = [ #{$1} ];"
end
File.write(file, fixed) if fixed != src
end
- Rename `services.rtl.cl-rest` to `services.clightning-rest`.
`clightning-rest` is generally useful for connecting external REST clients
to clightning.
- Add a dedicated network namespace in netns-isolation.
- Add nodeinfo entry.
- Add datadir (which contains REST auth data) to backups.
Split `enforceTor` into `tor.proxy` and `tor.enforce`.
By enabling `tor.proxy` without `tor.enforce`, a service can accept
incoming clearnet connections.
E.g., this allows setting up a Tor-proxied bitcoind node that accepts
RPC connections from LAN.
