Linux Café

I was running a hobbyist homelab on a Raspberry Pi 4 with 32 GB of eMMC storage. The Pi was a low‑cost, low‑power server that hosted a few services: a personal web server, a GitLab runner, and a Docker build farm for CI pipelines. The build farm was a simple script that pulled the latest code, built a Docker image, and pushed it to a registry. Everything worked until the disk filled up during a large multi‑stage build.

When the disk is almost full

I’ve run a handful of home‑servers for years, and the first thing that usually trips you up is a suddenly full disk.
Caches from apt, Docker, Flatpak, and the like can balloon without you noticing.
A quick, automated cleanup that only kicks in when the root filesystem is >90 % used keeps the system sane without you having to remember to run a script every week.

I’m ready to help, but I need the article text you’d like me to rewrite. Could you paste it in here?

On a small home‑lab server or a single‑user laptop, the root filesystem is often the first place that runs out of space. I ran into this on a 2025‑era Raspberry Pi running Ubuntu 24.04 LTS: the systemd journal kept growing until the root partition hit 95 % and the machine refused to boot. The fix was surprisingly simple once you understand how systemd‑journald works and how to steer its output away from the root filesystem.

When Clonezilla says root=UUID not found

Cloning a bootable SSD with Clonezilla is usually painless, but the new machine can stall at the kernel prompt with:

root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx not found

The kernel can’t locate the root filesystem because the UUIDs in the boot configuration still point to the original disk. The fix is a handful of targeted edits and rebuilds.

1. Verify the new UUIDs

Boot from a live USB, open a terminal and list the block devices:

Fast extraction of SSH failures with awk

When a server is exposed to the internet, the first line of defense is the log.
In most Linux distributions the file /var/log/auth.log (or /var/log/secure on RHEL‑style systems) contains every authentication event, including failed SSH logins.
If you need a quick snapshot of the last hour’s failures, you can do it in a single awk command that finishes in a fraction of a second, even on a 10‑GB log file.

Running containers without root is a lifesaver, but I hit a snag the other night. I had a small database container that wrote data to a named volume, and the next time I rebooted my machine the data was gone. Turns out the volume directory was being created under a transient mount that didn’t survive shutdown.

Why the Volume Vanishes

In rootless mode Podman keeps everything under ~/.local/share/containers/storage. When you do podman volume create, it records the mount point in a JSON file there. On reboot the user‑session systemd instance that owns the rootless runtime comes back up, but systemd doesn’t automatically remount the user‑created volumes unless you tell it to. The result? The container starts, and the volume looks like a fresh empty directory.

A night of memory chaos

I was running a 4 GB‑RAM VPS that hosts a handful of Docker containers and a personal website. A nightly backup script, scheduled with cron, suddenly started chewing through all RAM, triggering the OOM killer and bringing the whole machine to a halt. The crash happened on a Tuesday afternoon, and I had to reboot the server to get it back online. The lesson? Even a single misbehaving cron job can exhaust memory if you don’t guard against runaway processes. Below is a step‑by‑step guide on how I diagnosed the problem, added zram to give the kernel a memory cushion, and tweaked ulimit settings so that future cron jobs can’t over‑consume RAM.

I was staring at a blinking screen of a freshly flashed router when I realized the whole LAN had lost its DNS mojo. I could ping 192.168.1.1 fine, but curl example.com slammed back with “Could not resolve host”. No amount of dig or nslookup helped until I dug into systemd‑resolved.

Why systemd‑resolved Holds on to Old DNS

systemd‑resolved is the default resolver on most recent distros. It keeps a cache of answers to cut down on DNS traffic and speed things up. The cache is keyed by the DNS server that answered and the TTL that server advertised. When a router’s firmware changes, its DHCP server may hand out a new DNS IP or a new list of servers. systemd‑resolved will keep the old server in memory until it gets a fresh lease or the cache expires. If the new server is unreachable, all lookups die.

Cleaning up old temp files is a daily chore that can quickly become dangerous if you use the wrong tool.
A single misplaced rm -rf can wipe out a whole directory tree, and that risk grows when you’re running scripts as root.
The combination of find and xargs (or -delete) gives you a precise, race‑condition‑aware way to target only the files you really want gone.

Why find + xargs beats a blind rm -rf

• Scope control – find lets you restrict the search to a specific path, depth, file type, age, size, or owner.
• Safety – -delete removes only the matched files; it never walks into a directory you didn’t ask for.
• Speed – xargs batches deletions, reducing the number of rm invocations.
• Robustness – -print0 + xargs -0 handles filenames with spaces, newlines, or other odd characters.

A minimal, production‑ready command

# Delete regular files in /tmp older than 7 days
find /tmp -type f -mtime +7 -print0 | xargs -0 rm -v

• -type f skips directories and symlinks.
• -mtime +7 matches files whose modification time is more than seven days ago.
• -print0 outputs a null‑terminated list; xargs -0 consumes it safely.
• -v gives you a quick audit trail.

If you prefer a single‑step solution and your find supports it, replace the pipe with -delete: