How to Keep Your Podman “Hello‑World” Container from Filling Disk With Logs

Why a “Hello‑World” Container Can Become a Disk‑Hog

When you first dip your toes into Podman, the classic “hello‑world” test is the go‑to command. It’s fast, it’s tiny, and it proves the runtime is up and running:

podman run --rm docker.io/library/hello-world

A single run looks harmless, but if you fire it off repeatedly—say, in a cron job, a CI pipeline, or a home‑lab health‑check script—the logs that Podman keeps for each run can pile up. On a busy homelab, that accumulation can eat up several gigabytes in a matter of days, especially if you’re using the default local log driver that writes to a file on disk.

Below is a practical guide to keeping those logs from filling your storage. It covers the most common ways to silence or redirect logs, the trade‑offs of each approach, and a few troubleshooting tips that come up in real‑world setups.

1. Understand Where Podman Stores Logs

Podman supports several log drivers:

The default on most Linux distributions is json-file. That means every time a container writes to stdout or stderr, Podman appends a JSON object to the file mentioned above. If you run a container thousands of times, the file can grow quickly.

You can confirm which driver you’re using with:

podman info | grep -i log

2. Switch to the none Log Driver

The simplest way to stop logs from being written to disk is to tell Podman not to keep them at all. The none driver discards all output, but the container still runs and exits normally.

podman run --rm --log-driver=none docker.io/library/hello-world

Pros

• Zero disk usage – No log file is created.
• Fast – Writing to disk is avoided entirely.

Cons

• No visibility – You can’t inspect the output later, which is fine for a one‑off test but not for debugging.
• Security risk – If the container prints sensitive data, it will be lost instead of being stored securely.

When to Use It

• Automated health checks – If you’re only interested in the exit code.
• Short‑lived containers – Those that run once and exit quickly.
• Resource‑constrained devices – Where disk space is at a premium.

3. Redirect Output to /dev/null

If you still want Podman to keep a log file but you’re only concerned about the disk space, you can redirect the container’s stdout and stderr to /dev/null. This keeps the log file but makes it empty.

podman run --rm docker.io/library/hello-world > /dev/null 2>&1

Pros

• Keeps the log file – Useful if you need to enable logging later without changing the container definition.
• Simple – No need to change Podman configuration.

Cons

• Log file still exists – The file will remain on disk, albeit empty, and will still consume a few kilobytes.
• No visibility – Same as none, you lose the output.

4. Use the journald Log Driver

If you prefer to keep logs but want them in a central, rotating location, switch to journald. Systemd’s journal handles rotation automatically and can be configured to keep only a certain amount of data.

podman run --rm --log-driver=journald docker.io/library/hello-world

You can then view the logs with:

journalctl -u podman

Pros

• Centralized – All logs are in one place.
• Rotating – Journal can be configured to keep a fixed size or time window.
• Searchable – Use journalctl filters.

Cons

• Performance – Writing to the journal can be slightly slower than a plain file.
• Configuration required – You need to set up journal limits if you want strict disk usage control.

5. Configure Global Log Settings

If you want a blanket policy for all containers, edit the Podman configuration file (/etc/containers/containers.conf or ~/.config/containers/containers.conf). Add or modify the following section:

[logging]
driver = "none"

Or, to use journald globally:

[logging]
driver = "journald"

After editing, restart any services that use Podman (e.g., systemd --user sessions) to pick up the new defaults.

Trade‑offs

• Global change – All containers will inherit the setting, which may not be desirable for debugging or monitoring.
• Persistence – The setting survives reboots and new containers.

6. Manual Log Rotation for json-file

If you’re stuck with json-file and can’t change the driver, you can manually rotate the logs. The log file lives under the container’s overlay directory, but you can create a symlink or script to move old logs.

#!/usr/bin/env bash
# rotate-hello-logs.sh
LOG_DIR="/var/lib/containers/storage/overlay-containers"
for container in $(podman ps -a -q); do
  LOG_FILE="$LOG_DIR/$container/files/containers.log"
  if [ -f "$LOG_FILE" ] && [ $(stat -c %s "$LOG_FILE") -gt 10485760 ]; then
    mv "$LOG_FILE" "${LOG_FILE}.old"
    touch "$LOG_FILE"
  fi
done

Schedule this script with cron (e.g., every hour). Adjust the size threshold (10485760 bytes = 10 MiB) to fit your needs.

Pros

• Fine‑grained control – You decide when and how much to keep.
• No configuration change – Works with existing setups.

Cons

• Maintenance – Requires a script and cron job.
• Potential race conditions – If a container writes while you rotate, data may be lost.

7. Use a Lightweight Logging Driver

Podman 4.0 introduced a syslog driver that writes to the system’s syslog. It’s a middle ground between journald and json-file.

podman run --rm --log-driver=syslog docker.io/library/hello-world

You can then view logs with:

journalctl -t podman

or with classic syslog tools like rsyslog or syslog-ng.

Pros

• Centralized – Logs go to the system’s logging infrastructure.
• Configurable – You can set up rotation, filtering, and forwarding.

Cons

• Requires syslog daemon – Most distros have it, but it’s an extra component.
• Potential overhead – Writing to syslog can be slower than a local file.

8. Practical Example: A Cron‑Based Health Check

Suppose you run a nightly cron job that pulls the latest hello-world image and checks that it runs correctly. Here’s a minimal, safe setup that avoids filling disk with logs:

#!/usr/bin/env bash
# /usr/local/bin/check-hello.sh
set -euo pipefail

# Pull the latest image
podman pull docker.io/library/hello-world

# Run with no logs
podman run --rm --log-driver=none docker.io/library/hello-world

Add to crontab:

0 2 * * * root /usr/local/bin/check-hello.sh

Because the container is short‑lived and we’re not interested in its output, none is the perfect driver. No log files are created, and the job is lightweight.

9. Troubleshooting Common Issues

10. Security Considerations

While the focus here is disk usage, it’s worth noting that log files can contain sensitive information—environment variables, secrets, or debug output. By disabling logging (none) you avoid accidental exposure, but you also lose the ability to audit container behavior. If you’re running containers that handle secrets, consider:

• Using journald or syslog so logs can be rotated and stored securely.
• Encrypting the journal with systemd-journald’s Storage=volatile and RuntimeMaxUse settings.
• Running containers as non‑root to limit the impact of a compromised container.

11. Bottom Line

A “hello‑world” container is a great learning tool, but when you automate it, the default logging behavior can quickly become a nuisance. By choosing the right log driver—none, journald, or syslog—or by implementing a simple rotation script, you can keep your disk from filling up without sacrificing the ability to debug when needed.

For more details on Podman’s logging options, see the official documentation on the Podman GitHub page:

• https://github.com/containers/podman/blob/main/docs/reference/podman-run.md

Happy containerizing, and keep your disk space tidy!

See also

• How to set up a local Nginx reverse proxy for home‑hosted services without exposing ports to the internet
• Turning a Raspberry Pi into a DIY Caddy Reverse Proxy for Home‑Hosted Services
• Why My Custom Systemd Timer Keeps Firing Twice and How to Fix It
• Using find + xargs to purge old log files without risking accidental deletes
• Why I Swapped Traefik for Nginx Ingress in My Home Reverse‑Proxy Stack.