bitcoin: 30.2 -> 31.0
bitcoind: 30.2 -> 31.0
clboss: 0.15.1 -> 0.16.0
clightning: 25.12.1 -> 26.04.1
elementsd: 23.3.2 -> 23.3.3
lightning-loop: 0.31.5-beta -> 0.33.0-beta
lightning-loop 0.31.7+ blocks until lnd's chain notifier is ready
(lightninglabs/loop@bde49d7a), so the workaround sleep added in the
previous commit is no longer needed for lightning-loop. The
lightning-pool workaround stays — pool has no equivalent fix and
isn't actively maintained.
Note: nbxplorer test fails (presumed incompatibility with bitcoin 31).
bitcoin: 30.0 -> 30.2
bitcoind: 30.0 -> 30.2
bitcoind-knots: 29.2.knots20251110 -> 29.3.knots20260210
btcpayserver: 2.2.1 -> 2.3.4
clightning: 25.09.2 -> 25.12.1
elementsd: 23.2.4 -> 23.3.2
lnd: 0.19.3-beta -> 0.20.1-beta
lnd 0.20 makes its chain notifier subsystem ready later in startup
than its RPC server. lightning-loop and lightning-pool both subscribe
to chain notifications right after dialing lnd, which fails before
the notifier is up and crashes the daemon. Add a 5s ExecStartPre
sleep to both services as a temporary workaround.
Since version 257 (NixOS 25.05), systemd-nspawn automatically creates a
/dev/fuse node in the container when the host's FUSE node is accessible
to the nspawn process:
https://github.com/systemd/systemd/pull/34067
In `buildTests`, `nixInstantiate` is called in a subshell.
When `tmpDir` is unset before the call, the tmpdir is created in the
subshell and gets deleted before subshell exit (via `trap`).
But subsequent code accesses the tmpdir, which has now been deleted,
leading to an error.
This bug has been undetected for a long time because bash 5.2 has a
bug [1] where `trap` is not always executed, causing the tmpdir to never be deleted.
Bash 5.3 (introduced in NixOS 25.05) now works correctly and exposes the bug.
Fix it by creating the tmpdir before the subshell call.
[1] https://mail.gnu.org/archive/html/help-bash/2024-07/msg00007.html
Use `nix build --print-build-logs` to prefix the build output with the
name of its derivation.
This helps to distinguish build outputs when output is interleaved in
parallel builds.
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`.
Jonas Nick