If you own Dune tokens (DUN), you want them to work for the Dune network and ecosystem. It is a fun challenge and you will be rewarded for doing it. The more individual bakers we have in the Dune ecosystem the more decentralized and resilient Dune will become.

Granted, it takes a little bit of work — but good guides exist and I think you will find it worth while. This article focuses on getting you maximal uptime and ease of use once you have installed your node(s) and gotten your ledger to work.

Using systemd to control and monitor your node, baker, endorser and accuser

If you are not familiar with “services” or systemd there is a good intro here: https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units

Briefly, what we want is a stable system with maximal uptime in return for minimal intervention. As such we need a Dune node that starts itself once the system boots and a baker/endorser/accuser that is always on and ready to bake/endorse/accuse. systemd can easily help us achieve this.

Below you’ll find the config files for such a system together with some explanation of how it works.

Basically, for a full bakery we want to configure and (auto-)run four services

  • Dune Node
  • Dune Baker
  • Dune Endorser
  • Dune Accuser

For a node only, the bottom of this page has instructions on how to use systemd to run a non-baking node. It is super easy. If you only need that then you can read the dune-node.service part and then skip to the bottom of the document.

The individual files for a full bakery are outlined below. You can copy and paste them into the paths/files mentioned in each section.

dune-node.service

First we want to set up the service to run our Dune node. The below example includes running over VPN — you dont have to, just remove the openvpn-client@<vpnprovider>.service under the [Unit] both for Wants and After.

At the ExecStart line you can place whatever command you normally use to start your node – just dont use nohub etc. You can (& should) change your userand group to whatever you use on your system. I control my nodes in a simple config.json – but the below should work with default settings all over.

# The Dune Node service (part of systemd)
# file: /etc/systemd/system/dune-node.service 

[Unit]
Description     = Dune Node Service
Documentation   = http://Dune.gitlab.io/
Wants           = network-online.target
After           = network-online.target

[Service]
User             = baker
Group            = baker
WorkingDirectory = /home/baker/
ExecStart        = /home/baker/dune-network/dune-node run
Restart          = on-failure

[Install]
WantedBy	= multi-user.target
RequiredBy	= dune-baker.service dune-endorser.service dune-accuser.service

To install your Dune node as a service that loads at boot time you use systemctl:
sudo systemctl enable dune-node.service

Notice that we use After to tell systemd that this service should be loaded after networking is established. We allow the Dune-node service to load without network by using Wants as we might establish network later. You can make sure the Dune node would only load once network is established by chainging ‘Wants’ to ‘Requires’ but I would recommend against doing so, as it limits your flexibility. Same with the VPN service

To start your Dune node service you would use:
sudo systemctl start dune-node.service Obviously, you rarely use this command unless you 1) havent rebooted your system after installing the service or 2) you have actively shut down the service

To start your Dune node service I strongly recommend you use the reload-or-restart instead, as this would ensure (via systemd) that the service is started if not running already and reloaded if already running:
sudo systemctl reload-or-restart dune-node.service

To see the status of your Dune node service you would use:
sudo systemctl status dune-node.service

To stop your Dune node service you would use:
sudo systemctl stop dune-node.service

If for some reason you don’t want the node to start at boot anymore, simply do:
sudo systemctl disable dune-node.service

dune-baker.service

Now that the node is up and running we want to run the baker, endorser and accuser the same way.

# The Dune Baker service (part of systemd)
# file: /etc/systemd/system/dune-baker.service 

[Unit]
Description     = Dune Baker Service
Wants           = network-online.target
BindsTo		= dune-node.service
After           = dune-node.service

[Service]
User             = baker
Group	         = baker
WorkingDirectory = /home/baker/
ExecStartPre	 = /bin/sleep 1
ExecStart        = /home/baker/dune-network/dune-baker-all run with local node /home/baker/.dune-node ledger_bakerone_ed_0_0
Restart          = on-failure

[Install]
WantedBy	= multi-user.target

We know that these services require a Dune node and therefore we require the node to be running first — the hardest form of requirement is binding — this means that this service will only start if the service it BindsTo is successfully started and running. Also, if the service (Dune Node) this service (Dune Baker) binds to crashes this service will be stopped.

You should replace the ExecStart command with whatever command you want to run your baker with. Also, replace the ledger_bakerone_ed_0_0 with whatever alias your baking key has. Notice the ExecStartPre: It is a little hackish, but I found that introducing a one second delay between starting the node and the baker, endorser and accuser would make the service run smoothly. Else systemd will start them too closely together. There are ways to adjust this using sytemd, but to keep things simple, we simply sleep for a second prior to executing the command to fire up the baker.

We also know that it would probably be good to reload the baker, endorser and accuser should the node ever reload and therefore we use BindsTo to bind these services to the node. This effectively means, that all four services will restart if you restart the node and that you can restart each of the baker, endorser and accuser services seperately, should you need to.

Same commands as for node to enable, reload/start, stop and get status on the baker:

  • sudo systemctl enable dune-baker.service
  • sudo systemctl reload-or-restart dune-baker.service
  • sudo systemctl stop dune-baker.service
  • sudo systemctl status dune-baker.service

Note: You must have the Dune baking app open on your Ledger Nano S when you (re)start your baker and endorser.

dune-endorser.service

Now we simply do the same with the endorser and accuser daemons.

# The Dune Endorser service (part of systemd)
# file: /etc/systemd/system/dune-endorser.service 

[Unit]

Description     = Dune Endorser Service
Wants           = network-online.target
BindsTo         = dune-node.service
After           = dune-node.service

[Service]

User              = baker
Group             = baker
WorkingDirectory  = /home/baker/
ExecStartPre      = /bin/sleep 1
ExecStart         = /home/baker/dune-network/dune-endorser-all run ledger_bakerone_ed_0_0
Restart           = on-failure

[Install]

WantedBy	= multi-user.target

Same commands as for node to enable, reload/start, stop and get status on the baker:

  • sudo systemctl enable dune-endorser.service
  • sudo systemctl reload-or-restart dune-endorser.service
  • sudo systemctl stop dune-endorser.service
  • sudo systemctl status dune-endorser.service

Note: You must have the Dune baking app open on your Ledger Nano S when you (re)start your baker and endorser.

dune-accuser.service

# The Dune Accuser service (part of systemd)
# file: /etc/systemd/system/dune-accuser.service 

[Unit]

Description     = Dune Accuser Service
Wants           = network-online.target
BindsTo         = dune-node.service
After           = dune-node.service

[Service]

User             = baker
Group            = baker
WorkingDirectory = /home/baker/
ExecStartPre     = /bin/sleep 1
ExecStart        = /home/baker/dune-network/dune-accuser-all
Restart          = on-failure

[Install]

WantedBy	= multi-user.target

Same commands as for node to enable, reload/start, stop and get status on the accuser:

  • sudo systemctl enable dune-accuser.service
  • sudo systemctl reload-or-restart dune-accuser.service
  • sudo systemctl stop dune-accuser.service
  • sudo systemctl status dune-accuser.service

Combining all the services to get a nice status page for your Dune operations

sudo systemctl status dune-node.service dune-baker.service dune-endorser.service dune-accuser.service

Or alternatively, shorter but less ordered: sudo systemctl status 'dune-*.service'

You can restart all four services by restarting the node (because we bound the baker/endorser/accuser to the node):
sudo systemctl reload-or-restart dune-node.service

Similarly all services will stop upon:
sudo systemctl stop dune-node.service

And you can stop the baker/endorser/accuser individually if you want.

  • sudo systemctl stop dune-baker.service
  • sudo systemctl stop dune-endorser.service
  • sudo systemctl stop dune-accuser.service

Using front-end nodes and a private baker

The above configurations work for both front end nodes and for baking/endorsing/accusing nodes. If you want to use this (I recommend you do) for your front-end nodes too, simply remove the line RequiredBy = dune-baker.service Dune-endorser.service Dune-accuser.service from your dune-node.service and do not install the baker/accuser/endorser services.

Restarting your Dune operations automatically

Above, we use Restart:on-failure. You could use Restart:always – I just haven’t found it neccessary and there is a slight risk that – if combinded with loose restart settings – could exhaust your system. But feel free to try it out if it’ll make you sleep better at night. Now that you have all your Dune operations ‘servicified’ you can indeed start sleeping at night again, without loosing out on your baking and endorsing slots.

Using journalctl to monitor the node, baker, endorser and accuser

Sometimes it is neccessary to go through log files to identify root causes for different events and sometimes it is just fun to follow the your Dune services (=daemons) live. systemd has a very powerful tool to do this – it is called journalctl and a few examples on how to use it are given below.

To simply follow your node’s output real-time:
journalctl --follow --unit=dune-node.service

You dont really need to add the .service — but I’ll keep doing it here for clarity

Similarly with the baker, endorser and accuser:

  • journalctl --follow --unit=dune-baker.service
  • journalctl --follow --unit=dune-endorser.service
  • journalctl --follow --unit=dune-accuser.service

You can also get the output formatted to suit your needs. Try for example:
journalctl --follow --unit=dune-endorser.service --output=json-pretty

Dune runs its time by the universal timezone ‘UTC’ to get journalctl to output your log in utc simply add — utc:
journalctl --follow --unit=dune-endorser.service --utc

By now you’ve probably understood that the possibilities are almost endless and the flexibility is second to none. Try for example to get your log for the endorser after a given timestamp or between two timestamps by doing these:

  • journalctl --unit=dune-endorser.service --since=yesterday
  • journalctl --unit=dune-endorser.service --since=today
  • journalctl --unit=dune-endorser.service --since='2020-10-01 00:00:00' --until='2022-10-31 12:00:00'

Or find your bakes since last boot:
journalctl --unit=dune-baker.service --boot=-0 | grep candidate

If you have installed/compiled journalctl with pattern matching functionality you can do:
journalctl --unit=dune-baker.service --boot=-0 --grep=candidate

And on and on….

See more using man journalctl

Forget about cron jobs etc — systemd has you covered for some happy hands-off baking…

Enjoy!