Podman-rootless containers and systemd journal: default log driver decision

Short answer

No — Podman should keep the file-based (json-file) log driver as the rootless default and treat journald as an explicit opt-in. Auto-detecting a systemd user session and silently switching drivers would trade a predictable, inspectable log path for a conditional behavior that varies across hosts, breaks podman logs consumers, and can fail outright on systems without a functioning user journal.

Why the current default is the safer choice

The file-based driver works identically on every host: rootless, rootful, systemd or not. That uniformity is what makes podman logs a reliable contract for scripts, CI pipelines, and debugging. Journald integration is genuinely useful — centralized querying with journalctl, built-in rotation, and size caps — but it only works when the rootless process can reach a writable journal socket, which depends on XDG_RUNTIME_DIR, a valid machine ID, and a running user manager. Auto-detection would have to guess at all of that per-user, per-boot, and any wrong guess produces either silent log loss or permission errors at container start.

There is also a behavioral break: with --log-driver=journald, logs live in the journal rather than the container's log file, so podman logs output changes or becomes empty depending on version and configuration. Flipping that default based on session detection would break existing workflows on exactly the machines where detection succeeds — an inconsistent failure mode.

What a reasonable middle ground looks like

If tighter journal integration is the goal, better options than changing the default are:

• Documenting --log-driver=journald prominently for rootless users on systemd hosts.
• Supporting a per-user default in containers.conf (e.g. log_driver = "journald" under [containers]), so the choice is explicit and stable rather than detected at runtime.
• Emitting a warning when journald is requested but the user journal socket is unreachable, instead of failing cryptically.

Safeguards if you do opt into journald

• Permission checks: verify XDG_RUNTIME_DIR is set and the user journal is running (systemctl --user status systemd-journald is not applicable — the user journal is part of the system journal; check loginctl and that /run/user/$UID exists). Without these, writes can fail with permission denied.
• Journal overload: journald rate-limits and caps storage via /etc/systemd/journald.conf (SystemMaxUse, RateLimitIntervalSec, RateLimitBurst). Chatty containers can trigger rate limiting and drop messages — tune these before routing high-volume workloads.
• Rotation: journald rotates itself, which is an advantage over json-file, where logs grow unbounded in container storage unless you set --log-opt max-size or use external rotation.
• Avoid duplication: don't run both drivers for the same container; interleaved or duplicate entries make troubleshooting harder.

Verify before and after

# Confirm the active default driver
podman info --format '{{.Host.LogDriver}}'

# Test journald explicitly on one container
podman run --rm --log-driver=journald docker.io/alpine:latest echo hello

# Check the journal for the entry
journalctl _COMM=conmon --since "-5min"  # or filter by container ID

# Compare podman logs behavior under each driver
podman logs <container>

Behavior details (exact podman logs support under journald, journal field names) vary by Podman version, so verify on your installed release before committing a fleet to the change.

Bottom line

Keep json-file as the rootless default; make journald a deliberate, per-user or per-container choice via containers.conf or --log-driver. Auto-detection optimizes for convenience at the cost of predictability, and the failure modes — permission errors, rate-limited log loss, broken podman logs scripts — land on users who never asked for the switch.