pub enum LogRole {
Operator,
Service,
}Expand description
Whose diagnostics these are, and therefore which file they go in.
§Why the daemon does not share the operator’s file
On the two Unixes a boot-mode registration runs the daemon as root while
the four application-data directories stay in the operator’s profile —
05-infrastructure.md puts them there and service install records those
paths into the plist. So two accounts write into one logs/ directory, and
the appender creates its file with the umask default, 0644. Whichever
account opened today’s file first owns it, and if that was root the
operator’s own runner-manager status can no longer append to it.
That was not a degraded log. tracing_appender::rolling::daily panics
when it cannot open the file, so every CLI command on such a host died with
a backtrace before it did anything — reported on 0.1.17, on a host whose
daemon had rolled the file over at midnight as root:
thread 'main' panicked at rolling.rs:156:14:
initializing rolling file appender failed: InitError { context: "failed to
create log file", source: Os { code: 13, kind: PermissionDenied } }install no longer panics — see there — but not panicking would only have
turned a crash into an operator who never gets diagnostics again. The two
writers are separated instead, so neither can take the other’s file: the
account that runs the daemon owns SERVICE_LOG_STEM and the operator owns
OPERATOR_LOG_STEM, for as long as the registration lives.
Variants§
Operator
A command the operator ran, or a daemon they started in the foreground.
Service
The daemon a service manager started, which on a boot-mode host is a different account from the operator’s.