Linux Café

The 2‑second DNS lookup lag on a Pi – a hands‑on fix

I was running a Pi‑4‑based home‑lab that hosts a few services: a personal Git server, a small reverse‑proxy stack, and a few IoT sensors that ping the Pi every few seconds. Every time I pinged a domain that wasn’t in the local cache, I noticed a ~2 s pause before the first packet left the network interface. On a desktop that latency was negligible, but on the Pi it was a noticeable hiccup that made the sensor logs look a little jittery.

The 30‑second Nginx start‑up mystery on an 8‑core ARM box

I had a clean 8‑core ARM server (Cortex‑A72, 4 GB RAM) running Debian 12. Nginx was the only service that took longer than a couple of seconds to come up. The log said “started” after 30 s, but the system was idle otherwise. I wanted to know why a stateless web server was so slow to boot on a modern CPU.

I was in the middle of setting up a tiny homelab VM that bridges straight to the host. The guest could ping the gateway just fine, but ip addr show br0 was staring back at me with no inet line. The bridge was up, state UP, yet no IPv4. What’s going on?

1. Distinguish link‑state from IP‑state

ip link only tells you about the link layer. An interface can be physically up and still have no IP if the DHCP client never got a lease or a static config never ran.

Wayland is the default display server on most modern Linux distributions, but it can bite when you try to run GPU‑heavy games on a laptop. The problem isn’t that Wayland is broken; it’s that the default configuration prioritises smoothness over power‑saving. If you’re a sysadmin or a homelab hobbyist who also likes to play, you’ll find that a few targeted tweaks can give you both decent gaming performance and a respectable battery life.

Backups are the lifeblood of any homelab or small server. I usually run a nightly rsync job that copies hundreds of gigabytes from a production NFS share to a local Btrfs snapshot. On a 4‑core workstation the job is usually a quiet background task, but sometimes the process spikes to 100 % CPU and the terminal I use to monitor the job freezes. The culprit is often the default scheduling class and priority that rsync inherits from the shell.

Headphone jack gone silent after the 2026‑04 kernel update

I was mid‑streaming a podcast when the sound just… vanished. My 3.5 mm jack had been a reliable work‑horse for years, but after pulling the 5.15.12‑arch kernel I got nothing. The driver was still loaded, aplay -l still listed the jack, but the audio was dead. Turns out the culprit was a subtle tweak in ALSA’s power‑management for the HDA codec. A single udev rule and the jack was back in seconds.

Setting up Caddy as a reverse proxy for my home lab

I’ve been juggling a Plex server, Nextcloud, and a little Go API all on the same Ubuntu 24.04 box. The goal was simple: a tidy public URL for each service, automatic HTTPS, and as little upkeep as possible. Caddy 2.7 fit the bill perfectly—its ACME integration is a one‑liner, and it ships with HTTP/2 out of the box.

1. Install Caddy

sudo apt update
sudo apt install -y debian-keyring debian-archive-keyring
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | \
  sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/caddy-stable-archive-keyring.gpg] \
  https://dl.cloudsmith.io/public/caddy/stable/deb/debian any main" | \
  sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy

Caddy boots as a systemd service automatically. Just double‑check that it’s listening on the web ports:

The Problem

Running a rootless Podman container on a home‑lab server is great for isolation, but the logs it spits out can quietly eat up disk space. I once had a simple nginx container that, after a few days, filled a 20 GB SSD with log files. The container was running as my normal user, so I couldn’t just rm -rf /var/lib/containers/... without risking a permission error. The real issue was that Podman, by default, writes container stdout/stderr to files under /var/lib/containers/storage/overlay-containers/.../files/var/log/ and those files never rotate.

Recover a single file from a damaged Borg archive

When a Borg repository gets corrupted, the instinct is to dump the whole thing back. That’s usually overkill if you just need one config file. Borg actually gives you a fine‑grained extraction tool that can pull a single file even from a partially broken archive.

1. Verify the repository

borg check /srv/backups/myrepo

borg check will surface any integrity problems. If you see corruption, you can try to fix it:

Running a nightly backup from a home NAS to a desktop is a common task, but the copy can still hog the machine’s resources and make the UI feel sluggish.
The trick is to let the backup run with low CPU and I/O priority so the desktop stays responsive. Two simple tools—nice and ionice—are all you need.

Why the problem matters

When a rsync or tar job copies gigabytes of data, the kernel’s scheduler keeps the process in the foreground class. Even if you’re not actively using the machine, the backup can consume CPU cycles and saturate the disk queue. On a laptop or a desktop with a single NVMe drive, this shows up as a frozen terminal, delayed window redraws, or a sluggish browser.