Every pool operator out there needs some kind of scripts or software for keeping their Jormungandr nodes up and in sync. We wanted to have our own solution for that and so we created jManager.

JManager is a Jormungandr node manager implemented in Python and does that and a bit more. With the Shelley release around the corner our jManager is a bit later to the party but since we got some inquiries from pool operators for sharing the code we decided to do so.

In order to install jmanager head over to github jmanager-python and follow the documentation.

In the following section you can find description of various parameters that are not described in the main documentation.

JManager configuration parameters

There are two configuration files that jManager uses and you can read about them on the github doc. Here we’ll focus on parameters in jmanager_config.json. The jManager configuration is divided in sections:

• manager
• pooltool
• jormungandr
• emai
• nodes_config

The following sections describe the relevant parameters.

Manager

Manager section defines parameters that control the behavior of main module:

timeout_between_restarts – After a node is restarted it can take it a while to connect to the right peers. Sometimes it gets stuck. In such case jManager restarts the node again after the number of seconds specified

send_slots_within – How many seconds after a new epoch starts you want to send data to PoolTool

PoolTool

status_summary – Get the status summary from which the max lastBlockHeight reported to PoolTool is reported

send_slots – is used to send slots to PoolTool. You can define which method to use. The same functionality has been committed to PoolTool repository.

user_id – PoolTool’s user id

Jormungandr

supervisor_rest_api_url – This is the url for the REST API of supervisord

common_dir – this is the common dir, where the secret file resides and restarts log is created

timeouts:

• refresh_interval – how often the main loop turns (no need to change this)
• tip_timeout – How long to wait before declaring a the node to be out of sync. It checks if a node’s tip is moving at all.
• leaders_refresh_interval – how often checks for leaders logs (no need to change this)

tip_diff_threshold – if a node’s tip different for more than defined here from the max tip (max from all nodes and pooltool) the node is declared stuck and will be restarted.

Email

email_alerts: 0 – off, 1 – on

templates: templates with some predefined email text

Nodes config

node_name – the name of the node (will be seen in logs)

jmanager_settings:

• node_path – where your instance of jormungandr resides
• supervisor_service_name – name of the instance used by supervisor
• default_trusted_peers – this peers are merged with peers from config_template.json and are used when nodes cannot boot from each other’s (all stuck – kinda buggy and not well tested)

config – everything in here is just a jormungandr config. The values defined here are merged with config_template.json and overwrite any values found there.

Conclusion

You can easily leave most of the parameters on default values, the most important ones are the paths. Without setting those it won’t work.

A nice feature is configuration “hot” loading. You can modify the configuration and jManager picks up the new settings in a few seconds.

jManager is far from perfect but it works for us and we’ve been running it ourselves for a few months. We have a few ideas for improvement but we’ll see how things are setup in Haskell node.

If you find this post useful consider staking with TILX! Happy staking!