contrib/init: (OpenRC) use -daemonwait to wait for startup completion #24066

pull whitslack wants to merge 2 commits into bitcoin:master from whitslack:openrc-daemonwait changing 2 files +35 −17

whitslack commented at 8:33 AM on January 14, 2022: contributor

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 when it is started with the -daemon option. The -daemonwait option was added in 92cf3a22e (#21007) to address exactly this issue, so let's use it.

To avoid blocking startup for arbitrarily long, as users would be annoyed if agetty/display-manager doesn't start quickly, we now mark the bitcoind service initially as inactive at startup and then call back to OpenRC to mark the service as started (and proceed to start any dependent services) after bitcoind forks into the background.

This PR is a replacement for withdrawn PRs #22285 and #22354.

contrib/init: (OpenRC) use -daemonwait to wait for startup completion

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 when it is started with the -daemon option. The
-daemonwait option was added in 92cf3a22e (#21007) to address exactly
this issue, so let's use it.

To avoid blocking startup for arbitrarily long, as users would be
annoyed if agetty/display-manager doesn't start quickly, we now mark
the bitcoind service initially as inactive at startup and then call
back to OpenRC to mark the service as started (and proceed to start
any dependent services) after bitcoind forks into the background.

49287e0ab4

contrib/init: (OpenRC) use ${SVCNAME} in BITCOIND_PIDFILE default

This is just a good practice so that users can easily and safely clone
the bitcoind service using another name, such as bitcoind.testnet, and
the different services will have different pidfile names by default.

89cb2b6d91

DrahtBot added the label Scripts and tools on Jan 14, 2022
laanwj commented at 7:50 AM on April 14, 2022: member

Concept ACK, this is exactly what daemonwait is for.
whitslack commented at 12:36 AM on August 27, 2022: contributor

Has this PR stalled because no one with commit privilege uses OpenRC?
DrahtBot commented at 1:42 PM on September 23, 2022: contributor



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



Reviews

See the guideline for information on the review process.

Type Reviewers

Concept ACK laanwj, fanquake, luke-jr

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.



Conflicts

No conflicts as of last run.
fanquake commented at 12:26 PM on December 5, 2022: member

Has this PR stalled because no one with commit privilege uses OpenRC?

It's stalled because nobody else has tested it, reviewed it, left an ACK etc.
luke-jr commented at 11:55 PM on December 6, 2022: member

Concept ACK, but it feels hacky and I don't know OpenRC well enough to comment on whether this is just normal practice for similar services or not.

(Also, nit, would prefer to keep the command variables?)
whitslack commented at 12:29 AM on December 7, 2022: contributor

Concept ACK, but it feels hacky and I don't know OpenRC well enough to comment on whether this is just normal practice for similar services or not.

mark_service_inactive and IN_BACKGROUND are hacky, but that's how OpenRC does it. See OpenVPN for an example of another service that starts up in the inactive state and calls back into OpenRC later when the service is fully up and running. OpenVPN performs the callback from a script that the daemon spawns after establishing the VPN tunnel. That's how I originally implemented it for Bitcoin Core too, using the -startupnotify option, but I was told to use -daemonwait instead, so now the callback happens from a backgrounded subshell after bitcoind forks into the background.

(Also, nit, would prefer to keep the command variables?)

The default start() function, which uses those variables, doesn't support marking the service inactive at startup or forking a subshell to the background. I could rewrite my start() in terms of those variables if you really like to see the variables, but I think that's more confusing than inlining the values directly in the function.

Do you have any other ideas for how to fix the problem? To remind: the problem is that, using the currently shipped runscript, the bitcoind service reaches the started state despite not actually being ready to accept RPC requests from dependent services. OpenRC then starts dependent services, which immediately fail because bitcoind refuses their RPCs. The most straightforward solution is simply to add -daemonwait to the command line, but you (@luke-jr) expressed a concern about that potentially holding up the boot process for an unacceptably long time, so I addressed that concern with the background hack.

Are we just going to concede that the problem is unsolvable?
achow101 requested review from dongcarl on Apr 25, 2023
DrahtBot added the label CI failed on Apr 25, 2023
DrahtBot removed the label CI failed on Jun 9, 2023
DrahtBot added the label CI failed on Sep 18, 2023
achow101 requested review from TheCharlatan on Sep 20, 2023
DrahtBot removed the label CI failed on Sep 21, 2023
DrahtBot added the label CI failed on Jan 9, 2024
DrahtBot commented at 12:03 AM on April 8, 2024: contributor



🤔 There hasn't been much activity lately and the CI seems to be failing.

If no one reviewed the current pull request by commit hash, a rebase can be considered. While the CI failure may be a false positive, the CI hasn't been running for some time, so there may be a real issue hiding as well. A rebase triggers the latest CI and makes sure that no silent merge conflicts have snuck in.
achow101 commented at 2:32 PM on April 9, 2024: member

Are we just going to concede that the problem is unsolvable?

This PR does not seem to have conceptual support.
achow101 closed this on Apr 9, 2024
whitslack commented at 7:15 PM on April 9, 2024: contributor

For posterity: note that Gentoo switched to shipping its own local version of the OpenRC runscript for Bitcoin Core last year because this PR had stalled.
whitslack deleted the branch on Apr 9, 2024
bitcoin locked this on Apr 9, 2025