contrib/init: (OpenRC) use -startupnotify to wait for startup completion #22285

When other initscripts depend on bitcoind, it's because their daemons want to be able to invoke bitcoin-cli or to communicate with bitcoind via RPC. That can't happen until some time after bitcoind has forked into the background. The -startupnotify option was added in 090530cc24 (#15367) to support exactly this use case, so let's use it.

The ideal OpenRC mechanism of marking the service inactive at startup and later calling back into the start() function with IN_BACKGROUND=yes won't work here because bitcoind runs as an unprivileged user that is not allowed to call rc-service ${SVCNAME} start, and OpenRC has no mechanism like systemd-notify, so instead we make start-stop-daemon lock a startup dummy file with flock(1) before exec'ing bitcoind, and then we use -startupnotify to release the lock when bitcoind is ready to service RPC requests. In the initscript's start_post() function we lock the startup file briefly, which forces that function to wait until bitcoind has released its lock on the file, which will happen when bitcoind either executes the -startupnotify command or dies. After acquiring and releasing the lock, start_post() performs one final check that the pid file still exists, which allows the service to be marked as started or stopped appropriately.

<!-- *** Please remove the following help text before submitting: *** Pull requests without a rationale and clear improvement may be closed immediately. GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->

<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. -->

<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. -->

Not sure this is a good idea. If the user starts bitcoind at boot, he will need to wait potentially an annoyingly long time before he can login...?

Not sure this is a good idea. If the user starts bitcoind at boot, he will need to wait potentially an annoyingly long time before he can login...?

The other way I could do it would be to have the initscript mark the service as inactive and fork a subshell process into the background to wait for the lock and eventually reinvoke the initscript (with IN_BACKGROUND=yes) to mark the service as started so any dependent services can start in the background.

That said, if you're using rc_parallel=yes, then I think you'd get a login prompt before BitcoinD has finished starting anyway, assuming your login manager doesn't (transitively) depend on bitcoind, which I can't imagine it would.

I've never seen a login prompt before all startup has completed... (console login)

Oh, sure. SystemV init with the default Gentoo config won't start agetty until openrc is finished transitioning to the default runlevel.

So, would you be more amenable to this change if I did the background thing? To be honest, that's how I've had it set up on my machine for years (since long before -startupnotify was implemented), but I assumed the rather gross hackishness of that solution would be more objectionable than the straightforward approach.

I'm not familiar enough with the tradeoffs and implementation details, but it sounds like a better solution at face value.

Okay, I'll show you. Might take me a couple days to get to it.

@luke-jr: See #22354.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #22354 (contrib/init: (OpenRC) use -startupnotify to wait for startup completion [alternative] by whitslack)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Wouldn't -daemonwait help here? This option was added for doing a similar thing for the systemd script, and seems more straightforward.

Wouldn't -daemonwait help here? This option was added for doing a similar thing for the systemd script, and seems more straightforward. @laanwj: That's the option I was searching for when I started out on this project, as I was certain I'd seen it mentioned in the Bitcoin Optech newsletter, but it's not listed in --help, so I abandoned that avenue. Thanks for the pointer.

That said, -daemonwait won't address @luke-jr's concern, which I addressed in an alternative way using -startupnotify in #22354.

it's not listed in --help, so I abandoned that avenue. Thanks for the pointer.

Are you sure? It is mentioned in --help here:

  -daemonwait
       Wait for initialization to be finished before exiting. This implies
       -daemon (default: 0)

It's relatively new, so make sure you check with at least 22.x.

It's relatively new, so make sure you check with at least 22.x. @laanwj: Great! I don't run prerelease versions of Bitcoin Core, so I haven't seen it yet.

Nevertheless, naïvely using -daemonwait doesn't seem to be a good option here, as it would delay the completion of OpenRC's switch to the default runlevel at boot and thus will delay init's startup of agetty/login for longer than may be desirable. Perhaps it would be feasible to start bitcoind with -daemonwait in a backgrounded subshell and call back to OpenRC to mark the service as started after the bitcoind launcher process returns to the subshell. That would address @luke-jr's concern without using -startupnotify.