Choose a record backing for your site¶
dunscaith keeps one record per job. The supervisor commits every decision to it, and
status, watch and cancel read it. This guide covers where the records live and what to do
when dunscaith refuses the place it was given.
For why records are tied to one host, see How dunscaith hosts the supervisor.
Check what you have now¶
With no configuration, dunscaith keeps records under /var/tmp/dunscaith-$USER/. It creates the
directory with mode 0700 and writes a HOST file in it that binds the root to this host. Any
command that opens records reports a refused root before it does anything else, so run one:
A refusal is described below. If the root is acceptable, the
command goes on to the scheduler. In a build with no adapter linked, it then stops with no cluster
adapter, which here means the root is fine. With an adapter it prints reconciled <root>.
reconcile is safe to run at any time.
Choose a root¶
Only the file store exists in this build, so the choice is the directory it uses. It must be on a
filesystem local to the login node. NFS, Lustre, GPFS and BeeGFS are refused, because the record's
lock is only sound on one host.
dunscaith picks the root in this order, first match wins:
--root <path>on the command- the
DUNSCAITH_ROOTenvironment variable record.rootin configuration/var/tmp/dunscaith-$USER/
$USER, $HOME and a leading ~/ are expanded.
Set it once in configuration rather than on each command. Every host that reaches your jobs reads
the same configuration file, and a forwarded command resolves the root on the owning host from that
file. Do not rely on --root for jobs you will reach from another login node. See
Reach a job from another login node.
When dunscaith refuses the root¶
If the filesystem is not local, or is a RAM-backed one, dunscaith stops with:
record root /dev/shm/dr refused: ...: tmpfs loses every record on reboot; AcceptEphemeral acknowledges that
records must live on a filesystem local to this host; ways out:
- pass --root, or set DUNSCAITH_ROOT, to a local path
- set record.root in configuration (a site profile can set it for everyone)
- for a root that will not survive a reboot or pod restart, set record.ephemeral: true
- see https://dunscaith.phpboyscout.uk/how-to/choose-a-record-backing/
The first line names the filesystem type that was found. Pick the way out that matches it:
| Situation | Do this |
|---|---|
| Your home or default path is on a network filesystem | Point record.root at a local path such as /var/tmp/dunscaith-${USER}/ |
| The only local path is lost on reboot or pod restart (tmpfs, a pod-lifetime volume) | Point record.root at it and set record.ephemeral: true |
| A one-off | Pass --root or set DUNSCAITH_ROOT |
Declare an ephemeral root¶
record.ephemeral is a declaration, not a detection. dunscaith cannot tell from the filesystem type
that a directory lives only as long as a pod, so you say so:
Set it only for a root you know will not survive a reboot or pod restart. dunscaith then:
- accepts a RAM-backed root it would otherwise refuse;
- says
records under <root> do not survive a pod restart (record.ephemeral)once, in the submit receipt; - repeats
records do not survive a pod restart (record.ephemeral)in everystatus.
Losing a record loses the supervisor's memory of the job, not the job. The scheduler still has it,
and stop --emergency can still stop it by name.
Unknown territory¶
Whether /var/tmp survives on your cluster is not something dunscaith can know for certain. Many
sites clean it with systemd-tmpfiles after a set age, and login nodes can be reimaged. If either
is true for you, a record can vanish while its job runs. status then reports the record missing
and shows the last state from the job's pointer. Ask your administrators for a persistent
node-local path and use that as record.root.
The clean-up age warning¶
Where it can, dunscaith reads the clean-up age from the host's systemd-tmpfiles configuration:
the .conf files in /etc/tmpfiles.d, /run/tmpfiles.d, /usr/local/lib/tmpfiles.d and
/usr/lib/tmpfiles.d, a file in an earlier directory hiding one of the same name in a later one.
The rule that counts is the line for the record root or its nearest ancestor whose type cleans
(d, D, e, v, q, Q, C) and whose age is set. systemd-tmpfiles skips a path that has
an entry of its own, so any line, glob or not, for the root or an ancestor nearer than that
cleaning line means there is no clean-up: x, or a d with no age such as
d /var/tmp/dunscaith-%u 0700 - - -. X is the exception: it excludes only the directory itself,
not what is in it (tmpfiles.d(5)), so it does not protect the records under the root. Boot-only lines (!) do not run on the clean-up timer and
are ignored.
dunscaith expands %u, %U and %h as the user running it, %% as a percent sign, and the fixed
directory specifiers such as %V (/var/tmp). A line whose path holds a specifier it cannot
expand, such as %m or %H, and that might name the root or an ancestor, leaves the age unknown,
so dunscaith says nothing.
When a job's record was created longer ago than that age, status, supervise and reconcile
print a warning once for that job:
warning: the record of 01J9ZQ6E0KXV8M2T4N7P3R5A1B is 31 days old, older than the clean-up age 30d that /usr/lib/tmpfiles.d/tmp.conf:12 sets for /var/tmp; systemd-tmpfiles may delete it.
- for new jobs, set record.root (or pass --root, or set DUNSCAITH_ROOT) to a path the site does not clean
- or ask the site to exclude the root with a line such as `x /var/tmp/dunscaith-ada` in /etc/tmpfiles.d
- see https://dunscaith.phpboyscout.uk/how-to/choose-a-record-backing/
dunscaith remembers the warning in ~/.config/dunscaith/warned/<job>. Delete that file to see the
warning again. If the configuration is missing, unreadable, or holds a line dunscaith cannot
parse, it cannot read the age and says nothing.
A line whose type dunscaith does not know, such as one a newer systemd added, is ignored unless its path is the root or an ancestor. If it is, that line might clean or exclude the root, so dunscaith cannot judge the age. It says so once per command, naming the line, and carries on without the warning:
note: whether systemd-tmpfiles cleans /var/tmp/dunscaith-ada could not be judged: /etc/tmpfiles.d/site.conf:3: line type "Y" is not one dunscaith knows
An administrator who keeps the root with its
own line, such as x /var/tmp/dunscaith-* or d /var/tmp/dunscaith-%u 0700 - - -, turns the
warning off for everyone.
Other backings¶
record.store accepts only file. Other stores (Postgres, Kubernetes) are planned in
go/dispatch and will arrive as further values of the same key.