Linux Café

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.

I’m ready to help, but I don’t see the article you’d like me to rewrite. Could you paste it here?

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:

Running a single DNS server on a Raspberry Pi or a tiny VM is a common pattern in home labs.
When Let’s Encrypt asks you to prove domain ownership via a DNS‑01 challenge, the classic “edit a TXT record” dance becomes a chore if you’re juggling Cloudflare’s web UI.
Below is a quick, repeatable recipe that plugs a Pi‑hole into Cloudflare’s API, lets Cert‑bot finish the challenge automatically, and keeps the whole thing lean and secure.

Raspberry Pi’s are perfect for low‑power tinkering, but a 16‑GB microSD can start biting back if something writes too much data. After a year of unattended cron jobs, my Pi’s /var/log ballooned to 10 GB and the boot process stalled. Below is the exact walk‑through I used to bring the system back online and prevent a repeat.

Why the logs ate the SD card

The default Raspberry Pi OS ships with systemd‑journald for kernel and service logs and rsyslog for the classic syslog files. Both dump their output into /var/log. If you run cron jobs that spit out text and you don’t redirect or limit that output, each run just appends. Over a year, even a few megabytes per job can turn into gigabytes. The SD card’s limited write endurance means a bloated log file can accelerate wear‑out.

It looks like the article text didn’t come through. Could you paste the content you’d like me to rewrite? Once I have it, I can apply the style and technical rules you requested.

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.

I’d be happy to help polish it up! Could you share the article you’d like me to rewrite?

Why the Pi keeps swapping

I was running a memory‑hungry Python data‑pipeline on a 4 GB Raspberry Pi 4 when the system started thrashing every few minutes. top was showing swap usage climbing to 90 % while my script was still busy. The Pi’s 4 GB RAM was the hard limit, and the default swap file on the SD card was the culprit.

The culprit

The SD card is the only storage medium on the Pi, but it’s also the slowest. When the kernel starts paging, it writes to the swap file on the card, creating I/O bottlenecks that stall the Python interpreter. The swap file is defined in /etc/fstab:

When /boot runs out of space and the machine drops into emergency mode

A few minutes after a kernel update, you power on the server and the console shows:

System boot failed.
Emergency mode - type "journalctl -xb" to view logs.

The root filesystem is mounted read‑only, the initramfs cannot be loaded, and the machine refuses to start. The culprit is almost always a full /boot partition. In this post I walk through the exact steps to diagnose, free space, and reboot safely. I’ll cover the most common distributions, show how to keep the system lean, and touch on security best‑practices that come with kernel housekeeping.