Add comment how further options can be added or existing ones modified. Use /run/${RuntimeDirectory} for PID file.
Remove TimeoutStopSec, TimeoutStartSec, StartLimitInterval, StartLimitBurst directives as those should be set indivdually.
Remove Group to user the bitcoin user’s default group.
Changed Restart from ‘always’ to ‘on-failure’ (can also be overwritten individually).
Add comment how further options can be added or existing ones
modified. Use /run/${RuntimeDirectory} for PID file.
Remove TimeoutStopSec, TimeoutStartSec, StartLimitInterval,
StartLimitBurst directives as those should be set indivdually.
Remove Group to user the bitcoin user's default group.
Changed Restart from 'always' to 'on-failure' (can also be overwritten
individually).
It seems weird to move the datadir without the user noticing?
/var/lib/bitcoind seems to make more sense too. Without specifying it it will move to somewhere under /home, which is not recommended for a system-wide daemon.
Context: bitcoind’s service scripts (at least the openrc one) has always used the bitcoin user’s default datadir. This systemd script was incompatible with this for some reason.
At least on Gentoo systems, the bitcoin user’s home directory is itself /var/lib/bitcoin, so the datadir ends up as /var/lib/bitcoin/.bitcoin/
Besides what @luke-jr said, my rationale was that as few things as possible should be specified in the systemd service, all bitcoind specifics should go into /etc/bitcoin/bitcoin.conf. Thus the bare minium the service file has to specify how bitcoind should be invoked is
-daemon-conf=-pid=I’m not sure if it’s the case, but if command arguments override bitcoin.conf settings, then the user would not be able to change datadir without fiddling with the systemd service file.
But I’m happy to re-add -datadir if it’s deemed necessary.
What about TimeoutStartSec? #10531 increases it to 120s, this removes it completely.
The default is 90s, which is sufficient for most bitcoind setups I know. If a users has a particular cause for a different value (like a very slow system), then he can simply to override it, using the systemctl edit bitocind.service approach mentioned in the added comment block. That is what I meant with “should be set individually”. The idea is that systemd’s default are reasonable for most cases, and if it doesn’t work for someone, then systemd allows you override the defaults. I could be wrong, but I don’t see a reason why bitcoind should always need TimeoutStartSec set to 120s, instead of the default value (90s).
What does this timeout measure in the first place?
Good question. I can’t find anything in the documentation. And a short look at the source also didn’t help.
Until RPC becomes reachable? Or until it becomes usable?
I doubt that, since systemd has no specific knowledge of the service. I’d guess that for ‘forking’ type services like bitcoind, it’s the time the initial process needs to terminate.
What a pity. Needless to say that I believe this PR was an improvement over what is currently in the repo. ;)
The usual consumers are people who package bitcoind for their Linux distribution. For example, the Gentoo bitcoin overlay (which I’m involved with) and the Gentoo in-tree ebuilds would probably switch to the canonical bitcoind systemd files if they where in a good shape.
After discussion on IRC I’m reopening this.
(Apparently the current state is completely broken, so if there can’t be agreement on how to improve it, it’d be better to remove it completely.)
What does this timeout measure in the first place? Until RPC becomes reachable? Or until it becomes usable?
This is a forking service so timeout is just checking time until original foreground process exits successfully.
11-Description=Bitcoin's distributed currency daemon
12+Description=Bitcoin daemon
13 After=network.target
14
15 [Service]
16+ExecStart=/usr/bin/bitcoind -daemon -conf=/etc/bitcoin/bitcoin.conf -pid=/run/bitcoind/bitcoind.pid
/etc/bitcoind to be consistent with /run/bitcoind or /run/bitcoin to be consistent with /etc/bitcoin
/etc/bitcoin/ would make it a bit easier for the gentoo ebuilds, as that is what they currently use.
bitcoin-cli would ideally be able to use it too.
11@@ -12,7 +12,7 @@ Description=Bitcoin daemon
12 After=network.target
13
14 [Service]
15-ExecStart=/usr/bin/bitcoind -daemon -conf=/etc/bitcoin/bitcoin.conf -pid=/run/bitcoind/bitcoind.pid
16+ExecStart=/usr/bin/bitcoind -daemon -conf=/etc/bitcoin/bitcoin.conf -pid=/run/bitcoind/bitcoind.pid -printtoconsole -logtimestamps=0
-daemon and -printtoconsole - stdout will have nowhere to go after daemonization.
-daemon and -printtoconsole appeared to do the trick, but on a second look it sees that the log output stops after bitcoind demonized (possibly after the fork()?)
The idea was to let systemd handle bitcoind’s log output. At first using -daemon and -printtoconsole appeared to do the trick, but on a second look it sees that the log output stops after bitcoind demonized (possibly after the fork()?)
You could make work this by removing -daemon and -pid options, removing PIDFile setting, and changing Type setting from forking to simple. Personally, I would just want to use bitcoin logging, though, so logs can be more easily deleted if they contain private information, or if I enable verbose debugging and want to reclaim space. I would also leans towards using bitcoin logging here just to avoid adding unnecessary config overrides and differences between the way bitcoin functions inside and outside of systemd.