NAME

zerodds-durability-svc - ZeroDDS Durability-Service daemon

SYNOPSIS

zerodds-durability-svc --domain N [--store sqlite|file|lakehouse|postgres] [--path PATH] [--auto] [--topic NAME]... [--config YAML] [--set PATH=VALUE]...
zerodds-durability-svc [--config YAML] [--set PATH=VALUE]... --check-config

DESCRIPTION

zerodds-durability-svc keeps the samples of TRANSIENT and PERSISTENT topics (DDS 1.4 §2.2.3.4) for readers that join later, beyond the lifetime of the writers that wrote them. One daemon serves one DDS domain; it discovers the topics itself and replays their history to late joiners. PERSISTENT history survives a restart of the daemon when the store is durable.

A discovered writer's own retention policy — its DurabilityServiceQosPolicy (DDS 1.4 §2.2.3.5) — governs how long its topic's history is kept, unless the configuration file pins a contract for that topic explicitly; see zerodds-durability-svc.yaml(5), "WHICH CONTRACT WINS". A discovered topic's keyedness likewise comes from the writer (its RTPS entityKind, DDSI-RTPS 2.5 §9.3.1.2), not an assumption.

OPTIONS

Every option below is --set of its configuration key (see zerodds-durability-svc.yaml(5)): --domain N is --set domain=N, --topic NAME is --set +durability.topics=NAME, and so on — so the flag and an equivalent line in the file are the same setting, and whichever applies last (files, then flags) wins. Per-topic type/keyed/contract overrides have no flag: they are config-only (see zerodds-durability-svc.yaml(5)).

--domain N: The DDS domain id. Required (from this flag or the file).
--store KIND: The cold store: sqlite (default) or file; lakehouse (DuckDB) and postgres only in a build with the features of the same name.
--path PATH: Where the store lives: sqlite/lakehouse, a database file (omitted: in memory, lost on restart); file, a directory (required); postgres, a libpq connection string (required).
--auto: Serve every topic whose writers declare TRANSIENT or PERSISTENT durability.
--topic NAME: Serve this topic; repeatable. If the store already holds type/keyedness/ contract for it from an earlier run, it resumes immediately — no writer or reader has to be discovered first. Otherwise its type and keyedness resolve from whichever writer of it is discovered first (regardless of durability kind, since the topic was named explicitly), unless the configuration file names an explicit type for it. At least one of --auto and --topic is required (from any source, once every layer is merged).
--config YAML: The configuration file, with its drop-in directory YAML.d/; default: the system configuration directory. Holds this daemon's own settings (above) alongside the shared DDS runtime's.
--set PATH=VALUE: One setting above every file, repeatable; --set +PATH=VALUE appends to a list (e.g. another durability.topics entry).
--check-config: Validate and print the effective configuration — this daemon's own settings and the shared DDS runtime's — with the origin of every value, then exit (0 valid, 1 invalid value or unknown key, 2 unreadable file or syntax error).
-h, --help: Show usage.
-V, --version: Print version and exit.

FILES

/usr/lib/systemd/system/zerodds-durability-svc.service: The unit; its environment (ZERODDS_DURABILITY_DOMAIN, ZERODDS_DURABILITY_STORE, ZERODDS_DURABILITY_PATH, ZERODDS_DURABILITY_EXTRA) fills the command line. Default: domain 0, sqlite in /var/lib/zerodds/durability/dur.db, --auto.
/var/lib/zerodds/durability: The store directory of the unit, the only path it may write.

SIGNALS

SIGTERM and SIGINT stop the daemon: the pumps are joined and it exits 0.

EXIT STATUS

0: Stopped by a signal, or --check-config found the configuration valid.
1: An invalid command line or configuration value, or the store could not be opened.
2: A configuration file could not be read or does not parse.

AUTHOR

ZeroDDS Contributors

BEZEICHNUNG

zerodds-durability-svc - ZeroDDS-Daemon für den Durability-Service

ÜBERSICHT

zerodds-durability-svc --domain N [--store sqlite|file|lakehouse|postgres] [--path PFAD] [--auto] [--topic NAME]... [--config YAML] [--set PFAD=WERT]...
zerodds-durability-svc [--config YAML] [--set PFAD=WERT]... --check-config

BESCHREIBUNG

zerodds-durability-svc hält die Samples von TRANSIENT- und PERSISTENT-Topics (DDS 1.4 §2.2.3.4) für Reader vor, die später hinzukommen, über die Lebensdauer der Writer hinaus, die sie geschrieben haben. Ein Daemon bedient eine DDS-Domäne; er findet die Topics selbst und spielt ihre Historie für spät hinzukommende Reader ab. Die PERSISTENT-Historie übersteht einen Neustart des Daemons, wenn der Speicher dauerhaft ist.

Die eigene Aufbewahrungsregel eines gefundenen Writers — seine DurabilityServiceQosPolicy (DDS 1.4 §2.2.3.5) — bestimmt, wie lange die Historie seines Topics gehalten wird, außer die Konfigurationsdatei legt für dieses Topic ausdrücklich einen Vertrag fest; siehe zerodds-durability-svc.yaml(5), „WHICH CONTRACT WINS“. Ob ein gefundenes Topic Schlüssel hat, kommt ebenso vom Writer (seiner RTPS-entityKind, DDSI-RTPS 2.5 §9.3.1.2), nicht aus einer Annahme.

OPTIONEN

Jede Option unten ist --set ihres Konfigurationsschlüssels (siehe zerodds-durability-svc.yaml(5)): --domain N ist --set domain=N, --topic NAME ist --set +durability.topics=NAME, und so weiter — die Option und eine gleichwertige Zeile in der Datei sind also dieselbe Einstellung, und was zuletzt angewendet wird (erst Dateien, dann Optionen), gilt. Überschreibungen von type/keyed/contract je Topic haben keine Option: Es gibt sie nur in der Konfiguration (siehe zerodds-durability-svc.yaml(5)).

--domain N: Die DDS-Domain-ID. Pflicht (aus dieser Option oder der Datei).
--store ART: Der kalte Speicher: sqlite (Standard) oder file; lakehouse (DuckDB) und postgres nur in einem Build mit den gleichnamigen Features.
--path PFAD: Wo der Speicher liegt: sqlite/lakehouse: eine Datenbankdatei (weggelassen: im Speicher, bei einem Neustart verloren); file: ein Verzeichnis (Pflicht); postgres: ein libpq-Verbindungsstring (Pflicht).
--auto: Bedient jedes Topic, dessen Writer TRANSIENT- oder PERSISTENT-Durability deklarieren.
--topic NAME: Bedient dieses Topic; wiederholbar. Hält der Speicher aus einem früheren Lauf schon Typ, Schlüsseleigenschaft und Vertrag dafür, macht er sofort weiter — es muss vorher kein Writer oder Reader gefunden werden. Sonst ergeben sich Typ und Schlüsseleigenschaft aus dem Writer des Topics, der zuerst gefunden wird (unabhängig von seiner Durability-Art, weil das Topic ausdrücklich genannt ist), außer die Konfigurationsdatei nennt einen ausdrücklichen type dafür. Mindestens eine der Optionen --auto und --topic ist Pflicht (aus irgendeiner Quelle, nachdem alle Ebenen zusammengeführt sind).
--config YAML: Die Konfigurationsdatei mit ihrem Drop-in-Verzeichnis YAML.d/; Standard: das System-Konfigurationsverzeichnis. Enthält die eigenen Einstellungen dieses Daemons (oben) neben denen der gemeinsamen DDS-Laufzeitumgebung.
--set PFAD=WERT: Eine Einstellung über allen Dateien, wiederholbar; --set +PFAD=WERT hängt an eine Liste an (z. B. einen weiteren Eintrag in durability.topics).
--check-config: Prüft die wirksame Konfiguration — die eigenen Einstellungen dieses Daemons und die der gemeinsamen DDS-Laufzeitumgebung — und gibt sie mit der Herkunft jedes Werts aus, dann Ende (0 gültig, 1 ungültiger Wert oder unbekannter Schlüssel, 2 nicht lesbare Datei oder Syntaxfehler).
-h, --help: Zeigt die Aufrufhilfe.
-V, --version: Gibt die Version aus und beendet sich.

DATEIEN

/usr/lib/systemd/system/zerodds-durability-svc.service: Die Unit; ihre Umgebung (ZERODDS_DURABILITY_DOMAIN, ZERODDS_DURABILITY_STORE, ZERODDS_DURABILITY_PATH, ZERODDS_DURABILITY_EXTRA) füllt die Kommandozeile. Standard: Domäne 0, sqlite in /var/lib/zerodds/durability/dur.db, --auto.
/var/lib/zerodds/durability: Das Speicherverzeichnis der Unit, der einzige Pfad, den sie schreiben darf.

SIGNALE

SIGTERM und SIGINT beenden den Daemon: Die Pumpen werden zusammengeführt (join), und er endet mit 0.

EXIT-STATUS

0: Durch ein Signal beendet, oder --check-config hat die Konfiguration als gültig befunden.
1: Eine ungültige Kommandozeile oder ein ungültiger Konfigurationswert, oder der Speicher ließ sich nicht öffnen.
2: Eine Konfigurationsdatei war nicht lesbar oder nicht parsebar.

SIEHE AUCH

zerodds-durability-svc.yaml(5), zerodds-router(1), zerodds-admin(1)

AUTOR