Add systemd service to bitcoind in debian package #12769

pull ghost wants to merge 2 commits into bitcoin:master from changing 10 files +235 −9
  1. ghost commented at 1:46 PM on March 23, 2018: none

    On suggestion from @TheBlueMatt I have updated contrib/debian files to include a systemd service in the bitcoind build. Tested and working on Ubuntu 16.04 and 17.10.

    This fixes Issue #12758

  2. randolf approved
  3. randolf commented at 2:24 PM on March 23, 2018: contributor

    @ctp-tsteenholdt Please remember to squash/rebase.

  4. ghost commented at 2:57 PM on March 23, 2018: none

    @randolf That makes total sense. My apologies - looking into it right now...

  5. unknown closed this on Mar 23, 2018
  6. unknown reopened this on Mar 23, 2018
  7. laanwj commented at 7:36 PM on March 26, 2018: member

    We already have a bitcoind.service in contrib/init/ - what is the difference with this one, can we avoid duplicating it?

  8. ghost commented at 7:37 PM on March 26, 2018: none

    @randolf The pull request should look better now - please let me know if I'm missing something.

  9. laanwj added the label Scripts and tools on Mar 27, 2018
  10. ghost commented at 11:02 AM on March 27, 2018: none

    @laanwj I'm completely with you on that question, but I don't think we can feasibly avoid multiple versions of a file like this. The different versions of the bitcoind.service in the contrib/ tree have subtle differences to make them work best for their particular purpose. The differences reflect distro-specifics such as location of environment files, dependency services etc.

    Also, building a package for Ubuntu or Debian requires a full copy of the contrib/debian/ folder, including the bitcoind.service file, to allow the packaging helper dh to recognize, treat and install it correctly.

    It think distro-specific files are probably better maintained within distro specific folders such as contrib/debian/ or contrib/rpm/, as part of the overall package maintenance for that distro. This avoids possible breakage from a change made for a different distro too.

    To underline that the contrib/init/ version is still very relevant, it will be the goto file for people on platforms without a specific package or people who prefer to build from source. This file can be easily adapted to work well on most systems.

    Please let me know what you think.

  11. laanwj commented at 2:16 PM on March 27, 2018: member

    @ctp-tsteenholdt If it is intentional, then IMO it's not a problem. Arguably the debian-specific file is easier to maintain because at least it aims for a specific environment and can be tested there, not 'all distributions in general', which has made the file under contrib/init/ a real pain in practice (see e.g. discussion in #12255).

  12. ghost commented at 3:03 PM on March 27, 2018: none

    @laanwj That's exactly right.

  13. laanwj commented at 11:30 AM on March 28, 2018: member

    Would be good to have an ACK from @TheBlueMatt here.

  14. in contrib/debian/bitcoind.postrm:26 in dc1e178692 outdated 
      18 | +	echo
  19 | +	echo "#"
  20 | +	echo "#  The bitcoin user (${BCUSER}) and data dir (${BCHOME})"
  21 | +	echo "#  were left intact."
  22 | +	echo "#"
  23 | +	echo "#  After backing up all vital data, cleanup can be completed"
    TheBlueMatt commented at 5:54 PM on March 28, 2018:

    Maybe make it explicit that they should check /var/lib/bitcoin for things like wallets?

  15. in contrib/debian/bitcoind.service:15 in dc1e178692 outdated 
      10 | +[Unit]
  11 | +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
    TheBlueMatt commented at 5:54 PM on March 28, 2018:

    May be nice to make the datadir explicit so that we dont have /var/lib/bitcoin/.bitcoin and instead just put stuff in /var/lib/bitcoin?

  16. in contrib/debian/rules:16 in dc1e178692 outdated 
      12 |  override_dh_auto_clean:
  13 |  	if [ -f Makefile ]; then $(MAKE) distclean; fi
  14 |  	rm -rf Makefile.in aclocal.m4 configure src/Makefile.in src/bitcoin-config.h.in src/build-aux src/qt/Makefile.in src/qt/test/Makefile.in src/test/Makefile.in
  15 |  
  16 |  QT=$(shell dpkg-vendor --derives-from Ubuntu && echo qt4 || echo qt5)
  17 | +# qt4 is very broken on arm
    TheBlueMatt commented at 5:56 PM on March 28, 2018:

    Can you pull the backporting of existing debian/ contents out into a separate commit to make it easier to track?

  17. TheBlueMatt commented at 5:57 PM on March 28, 2018: member

    Looks good, though I didnt test any of it.

  18. ghost commented at 9:45 PM on March 28, 2018: none

    Thanks @TheBlueMatt. Each of your comments make perfect sense and I'll have them all addressed.

  19. ghost commented at 4:45 PM on March 29, 2018: none

    I've addressed the suggestions made by @TheBlueMatt, run a test dpkg-buildpackage using the updated contrib/debian/ tree and tested that the package changes work as expected, with success.

    The commits have been updated to reflect the changes.

  20. laanwj commented at 1:55 PM on April 7, 2018: member

    @TheBlueMatt can you take another look? Would be good to get this merged, I think.

  21. TheBlueMatt commented at 7:12 PM on April 17, 2018: member

    Hmm, if you're gonna pull some of the debian changes upstream, can you just pull all of them? Especially getting the changelog and other stuff out of sync seems not ideal.

  22. in contrib/debian/bitcoind.postinst:13 in 859eea683d outdated 
       8 | +BCHOME="/var/lib/bitcoin"
   9 | +
  10 | +if [ "$1" = "configure" ]; then
  11 | +
  12 | +	# Add bitcoin user/group - this will gracefully abort if the user already exists.
  13 | +	# A homedir is never created.
    TheBlueMatt commented at 7:13 PM on April 17, 2018:

    Why not create the directory? If its empty it will be deleted on uninstall, but if ther user ever tries to use the service things will simply fail to start, no?

    unknown commented at 2:25 PM on April 18, 2018:

    The reason for this approach is that, if for whatever reason the user has changed ownership or permissions on the /var/lib/bitcoin directory, we don't want to mess with that on operations like reconfigure, update etc.

    adduser does not let me specify custom homedir permissions, so I'm using --no-create-home to work around that. A missing home directory becomes a stable indicator that this is a fresh install, making it safe for me to create the directory and set the restrictive default permissions.

    TheBlueMatt commented at 2:41 PM on April 18, 2018:

    Oh, I misread the script, sorry.

  23. ghost commented at 2:38 PM on April 18, 2018: none

    @TheBlueMatt I'm not sure what you mean by:

    Hmm, if you're gonna pull some of the debian changes upstream, can you just pull all of them? Especially getting the changelog and other stuff out of sync seems not ideal.

    Upstream in this case would essentially be your PPA right? Or is there somewhere else?

    I can certainly take a look at any other differences between this tree and yours and see if it makes sense to include in this PR or create a separate one for getting those in sync? Is this what you mean?

  24. TheBlueMatt commented at 2:42 PM on April 18, 2018: member

    Yea, just pull the stuff from the PPA's debian tar.

  25. ghost commented at 3:22 PM on April 18, 2018: none

    Alright - I'm looking in to it...

  26. ghost commented at 7:26 PM on April 18, 2018: none

    @TheBlueMatt so I took all the changes from your upstream PPA debian tar and committed them as a single commit. After that, I committed the Systemd changes in a separate commit.

    As a precaution I've run a local build and made sure that things still work as expected.

  27. in contrib/debian/bitcoin-qt.desktop:13 in f3b62f85ad outdated 
       9 | @@ -10,5 +10,4 @@ Terminal=false
  10 |  Type=Application
  11 |  Icon=bitcoin128
  12 |  MimeType=x-scheme-handler/bitcoin;
  13 | -Categories=Office;Finance;P2P;Network;Qt;
  14 | -StartupWMClass=Bitcoin-qt
  15 | +Categories=Office;Finance;
    fanquake commented at 1:50 AM on April 20, 2018:

    These additional categories were just added in #12854

    unknown commented at 9:43 AM on April 20, 2018:

    @fanquake thanks. I'll get that sorted out here...

  28. Sync contrib/debian from Matt Corallo's PPA 9085532d35
  29. Add systemd service for bitcoind
    Adding systemd service for bitcoind, to provide for a simpler
out-of-the-box experience.

Configuration file is /etc/bitcoin/bitcoin.conf. This file is a
copy of the sample configuration file.

The service user 'bitcoin' is added during install. Its homedir
is in '/var/lib/bitcoin'.

bitcoind.service is disabled by default to allow the user to
configure it, before starting it the first time.

On package purge, the 'bitcoin' user as well as its homedir is
left intact, to not accidentally remove a wallet or something of
equal importance. Instead the user is presented with information
on how to perform the cleanup manually, after making sure all
important data has been backed up.
    2a87b1b07c
  30. ghost commented at 10:40 AM on April 20, 2018: none

    So I re-resolved the conflict with #12854. This time without nuking the accepted changes of that PR. Sorry about that. Thanks @fanquake for the heads up.

  31. laanwj commented at 6:48 PM on April 26, 2018: member

    @TheBlueMatt is this now ready for merge?

  32. ghost commented at 9:43 PM on April 26, 2018: none

    Just tested on Ubuntu 18.04, with no issues related to this PR. There is an unrelated issue with the libdb++ version that needs to be sorted out, so I built with --with-incompatible-bdb to test things out.

  33. in contrib/debian/rules:49 in 2a87b1b07c 
      45 | +		--no-enable
  46 | +
  47 | +# Restart after upgrade
  48 | +override_dh_systemd_start:
  49 | +	dh_systemd_start \
  50 | +		--restart-after-upgrade
    TheBlueMatt commented at 6:21 PM on April 27, 2018:

    Why? I dont think anyone would be surprised by their bitcoind going down prior to upgrade instead of only being restarted, and this could break eg a lxc VM as you'll get a text file busy error.

    unknown commented at 6:50 PM on April 27, 2018:

    @TheBlueMatt, good point.

    --restart-after-upgrade is default in dh_systemd_start from compat level 10, so the reason is perhaps best described as emulating modern defaults. I agree that for bitcoind, there should not be any real issues with using the defaults.

    I don't quite follow the problems you mention though. As far as I can tell, an upgrade should work perfectly, even when leaving the daemon running during the upgrade. Nothing runtime related is touched during the package upgrade, only the new bitcoind and bitcoin-cli binaries are put into place, making them ready for the late restart. Unless I'm missing something, this should be no different when running in a container?

    If you feel there's a risk here, I'll happily remove this!

    TheBlueMatt commented at 6:52 PM on April 27, 2018:

    Eh, if its default whatever, but linux generally refuses to replace binaries on disk if they are running inside of an LXC/docker container (though will happily do so during normal operation).

    unknown commented at 7:21 PM on April 27, 2018:

    Got it. I've never run into that problem, but haven't really come across a situation where such a setup would be needed. I tend to want to install apps like bitcoind inside my containers, in which case this would not be an issue.

    But if I wanted this kind of setup, I imagine I'd leave bitcoind disabled on the host and only start the service inside the container, right?

    If this is true, then the host level daemon would never be restarted on upgrade as the service is disabled, causing the restart to be skipped on upgrade. The container on the other hand would keep running the "old" in-memory binary, until it's restarted by some other means.

    I could be missing something...

  34. TheBlueMatt commented at 6:25 PM on April 27, 2018: member

    Looks good modulo the one restart question I had.

  35. TheBlueMatt commented at 6:53 PM on April 27, 2018: member

    utACK 2a87b1b07c5c4f8b9b34747c5f254c2ae1e824bf with or without restart-after-upgrade.

  36. luke-jr commented at 9:05 PM on April 27, 2018: member

    How will this affect systems that don't have/use systemd?

  37. ghost commented at 12:07 AM on April 28, 2018: none

    @luke-jr this affects only debian-based systems (including Ubuntu) with systemd.

  38. TheBlueMatt commented at 12:20 AM on April 28, 2018: member

    I believe @luke-jr's question was "what about older but still supported Debian-based systems that do not have systemd", which is a good one. WIll this not result in them failing to build the packages?

  39. ghost commented at 12:47 AM on April 28, 2018: none

    Older debian systems that are missing the dh-systemd package, will fail to build the packages, yes. I believe the (supported) Debian/Ubuntu versions that are affected by this, are Debian 7 (LTS version is EOL at the end of May 2018) and Ubuntu 14.04 LTS (EOL in April 2019).

    I'm running a test on Ubuntu 14.04 right now, to see what kind of issues we're running into on that platform.

  40. ghost commented at 1:57 AM on April 28, 2018: none

    As it turns out, Ubuntu 14.04 LTS actually does have a dh-systemd package and apart from the libdb4.8++-dev build dependency, that was also causing problems on Ubuntu 18.04, the build is working just fine.

    Since the distro does not actually use systemd, the included bitcoind.service simply does nothing.

    FWIW, Debian 7 also has a dh-systemd package (in the backports repository), so I guess it's the same story there.

  41. luke-jr commented at 2:59 AM on April 28, 2018: member

    I'm less concerned with merely old distros, as much as ones that have simply rejected the mandatory-systemd nonsense, such as Devuan.

  42. ghost commented at 8:28 AM on April 28, 2018: none

    @luke-jr to build the package, you'd need to have dh-systemd installed, but you do not need systemd to install or use it. If you don't have systemd on the system, you simply can't use the systemd service configuration that's included here.

  43. ghost commented at 1:45 PM on May 1, 2018: none

    Did that last comment answer your questions?

  44. laanwj commented at 2:52 PM on May 1, 2018: member

    I'm going to merge this as @TheBlueMatt utACKed this - he's the ppa maintainer. I don't think other distributions are relevant here as this concerns explicitly the debian directory. Other improvements can be made later.

  45. laanwj merged this on May 1, 2018
  46. laanwj closed this on May 1, 2018
  47. TheBlueMatt commented at 2:53 PM on May 1, 2018: member

    Err, no, Luke's point is good and would break several PPA-supported releases.

    On May 1, 2018 2:52:47 PM UTC, "Wladimir J. van der Laan" notifications@github.com wrote:

    I'm going to merge this as @TheBlueMatt utACKed this - he's the ppa maintainer. I don't think other distributions are relevant here as this concerns explicitly the debian directory. Other improvements can be made later.

    -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/12769#issuecomment-385690313

  48. laanwj referenced this in commit 35eb9d6c88 on May 1, 2018
  49. TheBlueMatt commented at 3:04 PM on May 1, 2018: member

    Oh, hmm, I appears to be wrong, it looks like the dh-systemd package is on trusty, I suppose its fine, then.

  50. laanwj referenced this in commit 1408d6cf76 on May 1, 2018
  51. laanwj commented at 3:38 PM on May 1, 2018: member

    Had to revert this, please file again in 2019 (or whenever relevant).

  52. ghost commented at 3:38 PM on May 1, 2018: none

    @laanwj, as @TheBlueMatt mentions in his followup, dh-systemd is indeed available on the relevant distributions - It certainly is on all supported versions of Ubuntu, Debian and Devuan. I can't see a reason to hold off on the merge?

  53. laanwj commented at 4:15 PM on May 1, 2018: member

    After discussion on IRC we're switching to a different strategy, distribution packaging files will be under this repository from now on: https://github.com/bitcoin-core/packaging (see also #13137)

  54. ghost commented at 4:28 PM on May 1, 2018: none

    Okay... Does this mean I should rework the changes to go in the new path then?

  55. MarcoFalke commented at 4:54 PM on May 1, 2018: member

    Indeed, just cherry-pick the commits and submit them to the other repo.

  56. ghost commented at 12:21 PM on May 2, 2018: none

    Thanks. I've created https://github.com/bitcoin-core/packaging/pull/1 with exact same changes...

  57. chris-belcher referenced this in commit 818157ebec on May 2, 2018
  58. stamhe referenced this in commit c14f6eaf64 on Jun 27, 2018
  59. lionello referenced this in commit 2aaef8f059 on Nov 7, 2018
  60. joemphilips referenced this in commit c180a19e37 on Nov 9, 2018
  61. MarcoFalke locked this on Sep 8, 2021
Contributors
ghostrandolflaanwjTheBlueMattfanquakeluke-jrMarcoFalke
Labels
Scripts and tools
Linked (view graph)
#12758 Add systemd service for debian bitcoind package (contrib)
github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-17 15:15 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me