How is the topology actually updated?

Many of us run the TopologyUpdater service from guild-operators, which first publishes the node’s IP and then fetches an updated topology. Up until now, I always assumed that the node somehow monitors its topology config file and reloads changes when they occur.

This does not seem to be the case and I was told that a node restart would be needed to reload the updated topology config. For obvious reasons, I don’t do an hourly restart of the node, in fact I very rarely do docker restart relay.

How do you update your topology?

PS: Up until now, I never questioned this, because the nodes were always well connected even without an explicit restart. With Alonzo, the need to explicitly update ones topology will likely go away, but still this puzzles me.

1 Like

I am restarting the relays once/12 hours… but default (topologyUpdater) it will restart once/24 hours;

deploying the topology updater as systemd will have the following services:


systemd service
The script can be deployed as a background service in different ways but the recommended and easiest way if was used, is to utilize the script to setup and schedule the execution. This will deploy both push & fetch service files as well as timers for a scheduled 60 min node alive message and cnode restart at the user set interval when running the deploy script.

  • cnode-tu-push.service : pushes a node alive message to Topology Updater API
  • cnode-tu-push.timer : schedules the push service to execute once every hour
  • cnode-tu-fetch.service : fetches a fresh topology file before cnode.service file is started/restarted
  • cnode-tu-restart.service : handles the restart of cardano-node(
  • cnode-tu-restart.timer : schedules the cardano-node restart service, default every 24h

Oh dear. Is that synced with the leaderlog in any way? You wouldn’t want to miss a block only because your script happens to restart the node.

of course, that’s why I never restart the relays same time :wink: there are 6 hours differences between

ok, +1 for redundancy.

So, although you get a topology update every hour, you only reload it once a day, right?

now, u can add peers manually from main topology, from trust pools and u will never have problems and perhaps no reload need

anyway u can monitor the number of peers in grafana… if are around 20 then it is not mandatory to reload the node

We are currently wondering, whether we should built this script based functionality into the “official” upstream docker image. Alonzo is supposed to support config reloads triggered by signals - I guess that would be the right time to add this functionality, if even needed by then.

I don’t know what to say…

When you press Ctrl+C on a foreground process, you sent the SIGINT signal to that process. The same can be done with all sorts of signals with the linux kill command.

Currently SIGINT causes the node to do a graceful shutdown, which SIGTERM does not do. The result of a non-graceful shutdown is that the node has to re-validate the entire block data base, which may take 15min. Therefore, never just pull the plug on your node :wink:

you are perfectly right :wink:

but my relay is starting faster


Yes, and this is because it probably does a graceful shutdown. In the terminal you should see "Shutting down ..."


With Alonzo the node will support config reload when you send it a specific signal (I don’t yet know which one) - a restart of the node won’t be necessary any more.

and also topologyupdater I think will be removed… P2P will replace it, if I understood well

1 Like

Yes. I therefore should probably first wait on the signal support (because requiring a restart is out of question) and then (and only if alonzo p2p gets delayed for some reason) can we build that script base topology update into the image.

1 Like

It is ridiculous that you have to restart the process simply to have it reread the topology file. This means every time the updater alters it, you have to restart the process. This sets off alerts every time (since we have it automated).

Is this documented anywhere? If not, why not? This should also reread the KES keys so rotation doesn’t also require a restart