Search
4 results for “journald”
Search results
Linux Logging & Monitoring with journald
Why journald's default "auto" storage mode can quietly discard logs across a reboot on a fresh system, and how journalctl's unit and priority filters actually narrow down a live incident.
What is the difference between journald's "volatile", "persistent", and "auto" storage modes, and which one is the default?
"Volatile" keeps the journal only in `/run/log/journal`, which is memory-backed and wiped on every reboot, nothing survives a restart. "Persistent" writes to `/var/log/journal` on disk, so entries survive reboots (falling back to volatile only during very early boot or if the disk is unavailable). "Auto" is the actual default, and it behaves like "persistent" only if `/var/log/journal` already exists, otherwise it behaves like "volatile", so whether logs survive a reboot on a given system depends entirely on whether that directory happens to have been created, not on any setting an administrator consciously chose.
What does journalctl -u myservice actually show you, beyond just log lines the service itself printed?
`-u`/`--unit=` expands into a filter that captures more than the service's own stdout/stderr, it includes messages logged about the unit by systemd itself (start, stop, failure notifications) and associated coredump information if the process crashed, correlated by the unit's identity rather than by manually grepping a shared log file for its name. This is more reliable than text-searching a combined log, since it's scoped by the actual unit metadata the journal records, not by whatever string happens to appear in a log line.
During a live incident, what does journalctl -f -u myservice -p err do, and why combine those specific options?
`-f` follows the journal in real time, printing new entries as they're appended, `-u myservice` scopes that stream to just the one unit under investigation, and `-p err` filters to only entries at the "err" priority or more severe (more important), suppressing informational noise. Combined, this gives a live, scoped, severity-filtered view of exactly one service's serious problems as they happen, rather than watching an unfiltered firehose of every unit's routine log output and trying to manually spot the relevant failure.