From 0627b7f1f38fb20386a62c24add4b180afd70ec9 Mon Sep 17 00:00:00 2001 From: jochen Date: Mon, 5 Oct 2026 18:09:44 +0200 Subject: [PATCH] Issue 255: the journal verb read nothing for a system service --- .../00-report.md | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 04-ISSUES/255-the-journal-verb-read-nothing-for-a-system-service/00-report.md diff --git a/04-ISSUES/255-the-journal-verb-read-nothing-for-a-system-service/00-report.md b/04-ISSUES/255-the-journal-verb-read-nothing-for-a-system-service/00-report.md new file mode 100644 index 0000000..fc89c1e --- /dev/null +++ b/04-ISSUES/255-the-journal-verb-read-nothing-for-a-system-service/00-report.md @@ -0,0 +1,32 @@ +--- +status: located +opened: 2026-10-05 +located-in: [mesh-catalog modules/systemd] +fixed-by: +amended-design: +--- + +# 255 — The journal verb read nothing for a system service + +## What was observed + +The service manager seat's `journal` verb answered "-- No entries --" for the controller's service on the +control node, while the service was logging steadily. Twice in one day a session reading the controller's +log fell back to a shell on the machine: the verb that exists for exactly that question answered nothing. +On one machine of four the same verb did answer: the only one whose operator account is in the journal's +group. + +## Diagnosis + +The module runs as the operator account and escalates the five acts on the system manager with `sudo -n`. +It ran `journalctl` unescalated. journalctl shows an account outside the journal's group only that +account's own entries, and says "-- No entries --" for everything else. That reads as a quiet service, not +as a refusal. + +The mesh grants the operator account passwordless escalation on every machine through its own drop-in, as +the sudo module's check confirms. + +## Fix + +A read of the system journal escalates like an act does. The account's own journal, in the user scope, +does not. The module was ported to Go as part of the fix, its tests with it.