Caching writes was causing us some issues if the startup of
`lightningd` didn't complete, i.e., the writes would happen on the
live DB, but we'd forget about them. Since we have the backup.lock
file in same directory as the plugin is running in, we no longer have
to defer the writes. This hugely simplifies our logic.
Fixes#155
Changelog-Fixed: backup: The plugin doesn't lose sync anymore if the startup is interrupted
We'll start relying solely on the `backup.lock` file generated by the
`backup-cli`. But we keep the option so we don't automatically break
all configs that simply updated.
Looking up the process parents and searching for `lightnignd` allows us to
kill directly. It also means we no longer have to wait for the RPC to be
enabled to abort.
We were writing logs directly before killing `lightningd` which resulted in
the logs being lost. The subsequent check for the log-lines then would fail
obviously.
Before this change, backup backend was initialized twice - in on_init()
and get_backend() functions. This change leaves only one call in
get_backend() and adds a kwarg determining whether init failure should
be fatal.
Signed-off-by: Michal Rostecki <mrostecki@mailfence.com>
We heavily rely on foreign key constraints to keep the DB consistent and drop
dependent objects such as UTXO set entries when we roll back a block. We also
need to enable the foreign key constraints when restoring otherwise these
dependents are not removed and we run into constraint violations.
