Skip to content

Resetting and removing

What resetting an enrolment invalidates, why enroll refuses a host that has an identity, and what becomes of the jobs of a disabled or deleted agent.

Three different things, done in the agent list by three different controls, and worth not confusing: a reset replaces the key, disabling puts the agent to sleep, and deleting removes it along with its history.

Resetting an enrolment

Reset enrollment is the path for two cases that are technically one: you have lost the agent's key (the machine is gone, the disk is gone, the token from the dialog was never used) and want to enrol the agent afresh, or the key has leaked and you want it revoked. Both do the same thing, and it is behind a confirmation, because it cannot be undone.

After a reset, Runjet shows the same dialog as at first enrolment, with a new token good for an hour, and writes an agent.reset row into the audit log.

Enrolling again on the host

Running the issued command on a host where an agent has been before is not enough. enroll refuses to overwrite an existing identity:

enroll: /var/lib/runjet-agent/identity.json already holds an identity, so this host is enrolled
	Re-enrolling would abandon a registration the scheduler still knows about. To
	start over, use Reset enrollment in the UI — it revokes the old key and issues
	a new token — then remove this file

So the procedure is:

  1. Stop the agent and remove the old identity:

    systemctl stop runjet-agent
    rm /var/lib/runjet-agent/identity.json
  2. Run the command from the dialog. agent.env already exists, so enroll leaves it alone and only prints what should be in it — three lines, unchanged unless you have changed workspace.

  3. systemctl start runjet-agent. The agent reports in with its new key and jobs start arriving again.

In a container this is deleting the named volume (or the file in it) and a new ENROLLMENT_TOKEN in the environment for the first start (container).

Disabling an agent

The Enabled switch on an agent's row takes it out of scheduling: ticks of the jobs aimed at it are skipped for it, and an agent that keeps reporting in is simply given no work. The history stays, the key holds, and enabling the agent puts it back in play with nothing to do on the host. It is the right choice for maintenance on a machine.

A disabled agent that is a job's only target means a job that does not run. The job list marks that, under assigning agents.

Deleting an agent

Delete agent is behind a confirmation, because the agent's run history goes with it — every run that ever happened on it is deleted too. A job aimed only at this agent is left with nowhere to run until you give it another. A job aimed elsewhere as well carries on running there.

Nothing happens on the host by itself. An agent still running gets a 401 to its next request, logs poll failed, and will keep trying every five seconds for ever. End it:

systemctl disable --now runjet-agent
rm -rf /var/lib/runjet-agent /etc/runjet-agent

If you want to keep the history and only take the agent out of service, disabling it above is the better choice. A deleted agent cannot be restored; only a new one with the same name can be registered, and that one begins with an empty history.