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`.
This test requires `electrs` to be enabled.
Also, by using `electrs` instead of `clightning` we avoid the bug
where clightning hangs at startup when internet access is unavailable.
Due to technical limititations, internet access is available in NixOS
containers only after the container has started.
Nix 2.24 is the default in NixOS 24.11.
This is required by the following commit that uses a `flake update`
command syntax only supported by Nix >= 2.19.
By wrapping the value in a list, users can add other `ExecStartPost` scripts.
The previous scalar value could only be replaced, but not merged with
other definitions.
These options are set by default in `jmclient/configure.py` and don't
need to be repeated.
Some options, like those in section `POLICY`, might be assigned more
suitable default values in future joinmarket releases, so don't override
them in nix-bitcoin.
Ensure that the file relative to the example scripts is called.
Previously, the unqualified call would give precedence to source files in
PATH. This could lead to the wrong file being called when dir
`helper` (containing another file named `start-bash-session.sh`) was in PATH.
By using the `default` flake module for tests, `pkgsUnstable` in
`pkgs/default.nix` gets passed the `nixpkgs-unstable` flake input
instead of falling back to importing `nixpkgsPinned.nixpkgs-unstable`.
For some use cases this prevents importing `nixpkgs-unstable` twice
(once via the `nixpkgs-unstable` flake input, once via
`import nixpkgsPinned.nixpkgs-unstable`).
- Add `doCheck = false` and `pythonImportsCheck` where appropriate.
This is good practice in general, but specifically works around a
`buildPythonPackage` bug where the test phase fails due to a
requirements check that is unrelated to testing.
- Enable tests for `jmbitcoin`.
- Patch some requirements. I've checked the release notes of the
required deps for backwards compatibility.
Without this, the `npm ci` command in `fetchNodeModules` hangs.
It seems that npm didn't check certs previously, because these are
not availble in Nix build environments by default.
Since PostgreSQL 15, DB users need to be DB owners to be able to create tables.
We can't use the new `ensureDBOwnerhip` NixOS option [1] to set this up,
because it requires the PostgreSQL user name and the database name to be
identical, which is not the case for btcpayserver.
Instead, we manually issue a PostgreSQL admin statement similar to the one
used by `ensureDBOwnerhip`.
This method of setting up the user is also compatible with older
PostgreSQL versions that come with older NixOS `system.stateVersion`s.
[1] https://github.com/NixOS/nixpkgs/pull/266270
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.
1. This simplifies the setup
2. Fixes a bug where a user skipped step 4.6 (run `nix-shell`) which
he deemed superfluous because a Nix shell was already active.
This caused an error during deployment.
Erik Arvstedt