contrib/init: (OpenRC) use -startupnotify to wait for startup completion [alternative] #22354
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. A straightforward and reliable way to wait for bitcoind to invoke its -startupnotify command is to make bitcoind hold a lock on a dummy file and release that lock via the -startupnotify command. The initscript's start_post() function initially marks the service as inactive and forks a subshell process into the background to wait for bitcoind to release the lock file, which will happen when bitcoind either executes the -startupnotify command or dies. After acquiring and releasing the lock, the subshell checks whether the pid file still exists and marks the service as started or stopped appropriately.
| -pid "${BITCOIND_PIDFILE}" \ | ||
| -conf "${BITCOIND_CONFIGFILE}" \ | ||
| -datadir "${BITCOIND_DATADIR}" \ | ||
| -startupnotify "flock -u 3") \ |
There was a problem hiding this comment.
Hmm, one side effect of using startupnotify here is that the user can no longer use it himself...
Maybe we need to fix this to allow multiple -*notify commands?
There was a problem hiding this comment.
I definitely think the -*notify options should stack, but I don't think that's a big concern with respect to this PR. If a user wants something to happen when bitcoind is ready to handle RPC requests, they would just create an initscript that depends on bitcoind and let OpenRC handle the sequencing.
|
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. |
This is an alternative to #22285 to address @luke-jr's concern.
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.A straightforward and reliable way to wait for bitcoind to invoke its
-startupnotifycommand is to make bitcoind hold a lock on a dummy file and release that lock via the-startupnotifycommand. The initscript'sstart_post()function initially marks the service as inactive and forks a subshell process into the background to wait for bitcoind to release the lock file, which will happen when bitcoind either executes the-startupnotifycommand or dies. After acquiring and releasing the lock, the subshell checks whether the pid file still exists and marks the service as started or stopped appropriately.