contrib/init: (OpenRC) use -startupnotify to wait for startup completion #22285
Conversation
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 090530c (bitcoin#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.
luke-jr
left a comment
There was a problem hiding this comment.
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 That said, if you're using |
|
I've never seen a login prompt before all startup has completed... (console login) |
|
Oh, sure. SystemV 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 |
|
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. |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
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 |
@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 That said, |
Are you sure? It is mentioned in 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 |
When other initscripts depend on bitcoind, it's because their daemons want to be able to invoke
bitcoin-clior to communicate with bitcoind via RPC. That can't happen until some time after bitcoind has forked into the background. The-startupnotifyoption was added in 090530c (#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 withIN_BACKGROUND=yeswon't work here because bitcoind runs as an unprivileged user that is not allowed to callrc-service ${SVCNAME} start, and OpenRC has no mechanism likesystemd-notify, so instead we makestart-stop-daemonlock a startup dummy file withflock(1)before exec'ingbitcoind, and then we use-startupnotifyto release the lock when bitcoind is ready to service RPC requests. In the initscript'sstart_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-startupnotifycommand 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.