DCP Worker for RHEL 9

CPU-only build · install, register, and run · tested on RHEL 9.0, 9.6, and 9.8

Pilot status — read this first. This is a working engineering pilot, confirmed end-to-end (install, registration, restart persistence, live scheduler connection) on real RHEL 9 — but it is not yet an officially supported, GA Distributive product the way the Ubuntu .deb/apt package is. Good for evaluation and non-production trials.

See "What production-grade would add," below, for the full list and what each item is actually for.

Before you start: you'll need your own registration key from your Distributive account — it is not included in this package. If you don't have one, get it from your Distributive account/portal, or contact Distributive, before step 3.

Download
dcp-worker-rhel9-cpuonly-7.11.0-package.tgz
Installer package + setup script. Extract and run setup.sh.
Download

One OS package may be needed first: some minimal RHEL installs don't ship libatomic by default, which the bundled node requires. setup.sh checks for this automatically at the end of install and tells you clearly if it's missing — or install it upfront with sudo dnf install -y libatomic.

1 Install

tar -xzf dcp-worker-rhel9-cpuonly-7.11.0-package.tgz
cd rhel2026
sudo ./setup.sh

This creates a dedicated, unprivileged dcp system user, installs everything under /opt/dcp, and installs (but does not yet start) three systemd services: dcp-worker, dcp-evaluator, and dcp.

Then load the new service files:

sudo systemctl daemon-reload

2 Register the worker (one-time)

Registration links this machine to your own Distributive account so your earnings and worker activity are tracked correctly. You only do this once per machine — the worker saves its identity to disk (/opt/dcp/.dcp/id.keystore) and reloads it automatically on every future start, including after a reboot.

Replace <your-registration-key> with the key from your own account:

sudo -u dcp /opt/dcp/bin/node \
  /opt/dcp/bin/dcp-supervisor/node_modules/dcp-worker/bin/dcp-worker \
  --register=<your-registration-key>

You'll see something like:

Registration complete; worker <worker-id> now managed by <your-account-address>

That's it — the command exits after registering. It does not start the worker; that's the next step.

Already registered this machine before? Skip this step — the identity file already exists, and re-registering isn't necessary (though it isn't destructive if you do).

3 Start the worker

Both services need to be enabled and started — dcp-evaluator runs the actual job sandbox, dcp-worker is the supervisor that talks to the scheduler and dispatches work to it: 

sudo systemctl enable --now dcp-worker dcp-evaluator

enable --now both starts it immediately and sets it to start automatically on every future boot — no manual restart needed after a reboot, a crash, or a systemd recovery. Both services already have Restart=always configured, so a crashed evaluator sandbox or a network hiccup on the worker side recovers on their own too.

4 Confirm it's running

sudo systemctl status dcp-worker dcp-evaluator --no-pager

Both should show Active: active (running). To watch live logs:

sudo journalctl -f -u dcp-worker -u dcp-evaluator

A healthy startup looks like:

. Configured for scheduler https://scheduler.distributed.computer/
. Bank is https://bank.distributed.computer/
. Identity is 0x...
. WebGPU not enabled
. Scheduler supports worker type(s) v4 and operations 1.0.0
* Ready.

WebGPU not enabled is expected and correct — this is the CPU-only build. Press Ctrl+C to stop watching logs (this does not stop the worker).

A note for your network/security team: this build always launches with Node's --use-system-ca flag, so the worker trusts whatever certificate authorities are in this machine's own managed trust store — anything installed via update-ca-trust (e.g. an internal corporate CA, or a TLS-inspecting proxy's certificate), not just the certificates the worker ships with. If your network requires outbound HTTPS to be trusted via a custom/internal CA, add it the standard RHEL way and the worker picks it up automatically, no worker-specific configuration needed: 

sudo cp your-ca-cert.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

5 Stopping / restarting

sudo systemctl stop dcp-worker dcp-evaluator      # stop
sudo systemctl start dcp-worker dcp-evaluator     # start again
sudo systemctl restart dcp-worker dcp-evaluator   # restart

Stopping and starting again does not require re-registering — the saved identity is reloaded automatically every time.

6 Optional configuration

To set an earnings payout account, join a specific compute group, or adjust CPU/sandbox limits, edit the worker's systemd unit: 

sudo vim /etc/systemd/system/dcp-worker.service

and add flags to the ExecStart line, e.g.:

ExecStart="/opt/dcp/bin/dcp-worker.sh" --output=console \
  --earnings-account=<your-bank-account> \
  --join=<compute-group-key>,<compute-group-secret> \
  --no-global \
  --utilization=1 \
  --cores=4
--earnings-account
where payouts get deposited.
--join=key,secret
join a private compute group (repeat to join more than one).
--no-global
opt out of the public Global Compute Group, so this worker only ever runs jobs from the compute group(s) you explicitly --join. Include this if you only want it running your own private workloads, not public/anonymous jobs from the wider DCP network. Omit it if you're fine with both.
--utilization / --cores
how much of the machine's CPU to offer.

Then apply the change:

sudo systemctl daemon-reload
sudo systemctl restart dcp-worker

7 Uninstalling

sudo systemctl disable --now dcp-worker dcp-evaluator
sudo rm -rf /opt/dcp /etc/systemd/system/dcp.service \
  /etc/systemd/system/dcp-worker.service \
  /etc/systemd/system/dcp-evaluator.service
sudo systemctl daemon-reload
sudo userdel dcp

This deletes the worker's saved identity. If you plan to reinstall later on the same machine and want to keep the same worker ID, back up /opt/dcp/.dcp/id.keystore first.

8 What production-grade would add

The list below is what turns this from "a working pilot we tested ourselves" into an officially supported enterprise product. None of it blocks evaluating the worker today — it's the gap between pilot and GA.

Packaging & provenance

Build pipeline

Update methodology

Security

Support

Compliance (worth checking, not necessarily new work)

9 Troubleshooting

systemctl status shows failed or inactive: check sudo journalctl -u dcp-worker -u dcp-evaluator --no-pager | tail -50 for the actual error.

Worker log says "Waiting for dcp-evaluator... to start" and never proceeds: dcp-evaluator isn't running — check sudo systemctl status dcp-evaluator and make sure it was enabled and started (step 3).

libatomic.so.1: cannot open shared object file: run sudo dnf install -y libatomic — a minimal RHEL install is sometimes missing this. setup.sh checks for this automatically and should have already told you, but this is the fix either way.