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.

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:

The night I lost an off‑site Borg backup

I run a 24/7 home‑lab server that backs up my home directories to a remote NAS with Borg. The backup is triggered by a systemd timer that fires every night at 02:00 UTC. For months it worked flawlessly, but one morning the timer ran, the job logged “ssh: connect to host …: Permission denied”, and the backup vanished into the night. The culprit? A forgotten SSH key.

Running a nightly backup script after logout with systemd user units – no nohup needed

I set up a little home‑lab server last year and wanted a way to snap my home directory every night without tying the job to a terminal. The old nohup trick works, but it leaves orphaned processes and you end up chasing logs in the dark. Systemd user units give a cleaner, more reliable solution that plays nicely with the rest of the system.

PulseAudio CPU Hogging

If your laptop’s fan has been doing the back‑and‑forth dance or the CPU clock keeps climbing while you’re just listening to a playlist or watching a video, you’ve probably run into PulseAudio’s infamous CPU bloat. The daemon is built for flexibility, not for squeezing every watt out of a laptop, and its out‑of‑the‑box settings can turn a modest machine into a little CPU hamster.

Why PulseAudio Can Be a CPU Hamster

The resampling engine runs in user space and gets hit for every stream that needs a sample‑rate or format change. By default it uses soxr, a high‑quality but heavy algorithm. Combine that with the default 48 kHz sample rate and 32‑bit float format, and you’re looking at a few percent of a core even when the system is otherwise idle. On older hardware or when the battery is low, that overhead shows up as a fan spin or a temperature spike.

Introduction to Slow Boot Times

I’ve been running Linux on my laptop for years, and slow boot times have become a major frustration. As someone who values productivity, waiting for my system to boot up can be a real pain. So, in 2025, I decided to dive into the world of systemd and see if I could optimize my boot process.

Understanding systemd

Before you start tweaking, it’s crucial to understand how systemd works. systemd is a system and service manager that’s responsible for booting and managing your Linux system. It’s complex, but there are some great tools available to help you understand and optimize it. One of the most useful tools is systemd-analyze, which provides detailed information about the boot process.

Introduction to Troubleshooting Slow DNS Lookups

I’ve been running a Linux homelab server for a while now, and one issue that’s caught my attention recently is slow DNS lookups. With the increasing reliance on online services, fast and reliable DNS resolution is crucial. I noticed my server was taking longer than usual to resolve domain names, affecting my homelab’s overall performance. After digging in, I found the issue was related to systemd-resolved, the DNS resolver service that comes bundled with systemd. I’ve seen this go wrong when the default resolvers aren’t responding quickly.

Introduction to Journalctl Noise

I’ve spent years relying on journalctl for system logging and debugging, but I’ve found myself wasting too much time sifting through useless logs. The noise was becoming a significant problem, making it tough to identify real issues. I’ve seen this go wrong when trying to troubleshoot a critical issue, only to get bogged down in irrelevant logs.

Understanding Journalctl

journalctl is a powerful tool provided by systemd, and it’s essential to understand how it works. The real trick is to learn how to use its features effectively. The systemd.io website has extensive documentation on journalctl, which is definitely worth checking out. Don’t bother with trying to memorize every option, though - just get familiar with the basics and build from there.

Introduction to Journalctl Filtering

I’ve seen this go wrong when you’re trying to troubleshoot an issue and journalctl spits out a wall of text. By default, it displays all available log messages, which can be overwhelming, especially on systems with many services running. The output includes the timestamp, hostname, syslog identifier, and the actual log message. To make sense of this output, you can use various options and filters provided by journalctl.