Pull the top 10 HTTP status codes from an Nginx access log with awk

When you’re running a small site or a homelab server, the access log is the first place you look for clues about what’s happening. A quick glance at the most frequent status codes can tell you whether a recent change broke something, if a bot is hammering your API, or if a mis‑configured rewrite is returning 404s for legitimate pages.
Below is a practical, one‑liner‑heavy walk‑through that shows how to extract the top ten status codes from a standard Nginx log using only awk. It covers common pitfalls, performance tricks, and a few security‑related notes that fit naturally into a daily‑use workflow.

When a Borg backup stops halfway

You’re in the middle of a nightly backup of your homelab server, the progress bar hits 50 % and then the process dies. Maybe a sudden power loss, a network hiccup, or a disk error. The archive on the remote storage looks like a half‑filled container. You’re left with a repository that has a partially written archive. How do you recover the data you already captured, and how do you finish the backup without starting from scratch?

Keeping a Home Server Alive During Let’s Encrypt Renewals

Let’s Encrypt certificates are only good for 90 days. On a little home box that runs a handful of services—web, mail, VPN, media—any hiccup during renewal can bring the whole stack down. I’ve seen this happen once: the renewal script fired, nginx restarted, and the firewall dropped all traffic. The fix I settled on is a single systemd.timer that guarantees the renewal runs in a safe window, with a fallback that keeps services up if something goes wrong.

Pin a Flatpak App to a Fixed Version on Wayland

Flatpak apps are great for sandboxing, but the automatic update loop can be a nuisance when a new release breaks a workflow or introduces a regression. On a Wayland‑based desktop (GNOME, KDE, etc.) the update mechanism is the same as on X11, so the steps below work everywhere.

1. Inspect the current version

flatpak info com.spotify.Client

The output shows the installed commit hash and the remote’s latest commit. If you’re running a version that you want to keep, note the commit hash:

The journal can drown you in Wi‑Fi disconnect chatter

Ever notice your laptop or Raspberry Pi stuck in a loop of “connected” / “disconnected” messages? The kernel, NetworkManager, wpa_supplicant – they all go on about it. On a busy box the journal gets clogged with the same line over and over, and your console turns into a flood of warnings that look like fresh problems every few seconds. If you’re a homelab operator, a self‑hoster, or just a sysadmin who likes a tidy log, you’ll want a clean way to silence the noise without losing the diagnostics that help you spot real outages.

When a simple umask change turned my Downloads folder into a ghost

I was tweaking my user profile in the middle of a busy afternoon, trying to tighten up file permissions for a fresh install of Arch Linux. I had just set umask 027 in my ~/.bashrc to make new files group‑readable but not world‑readable. A few minutes later I opened my file manager, clicked on Downloads, and the folder was gone. No error, no warning—just an empty directory listing. The rest of my home directory looked fine, but the Downloads folder was missing, and all the files I had just downloaded were nowhere to be seen.

Stale IPs on a Home Network? Let dnsmasq Clean Up the Mess

If you’ve ever pinged a device that had moved to a new address and the reply came from an old IP, you’ve probably been frustrated by the same stale DNS entries that linger in the resolver cache. On a typical Ubuntu desktop or server, systemd‑resolved is the default DNS stub. It’s great for most use cases, but it can keep outdated records for a long time, especially when your router’s DHCP server changes leases frequently. The result? Your own machine keeps trying to resolve a dead address until the cache finally expires.

Nightly rsync vanished after moving to systemd timers

I had a simple nightly backup script that ran under cron for years. One evening I decided to modernise the scheduler: replace the crontab entry with a systemd timer. The idea was clean, the logs would be in journalctl, and I could keep the backup logic in a single unit file. A few days later the backup disappeared from the destination directory. After a quick audit I discovered that the timer had never fired because the system had been powered off at the scheduled time. The culprit was the missing Persistent=true setting.

Why CPU Spikes Hurt Your Backup

Running a nightly backup with rsync or tar is a staple of any homelab or self‑hosted server. Even if the backup finishes in a few minutes, a sudden burst of CPU usage can push the system into a state where interactive work stalls, background services lag, or even the backup itself stalls due to contention. On a machine that also hosts a web server or a desktop, those spikes become noticeable. The good news is that Linux gives you two lightweight knobs—nice and ionice—to dial the priority of a process without touching the kernel or installing extra software.

Install Podman and Enable User Namespaces

sudo apt update
sudo apt install -y podman

On Debian 12, Podman ships with userns-remap turned off.
I always enable it right away by editing /etc/containers/containers.conf:

[engine]
userns = "keep-id"

keep-id keeps the container’s UID/GID the same as the host user’s, which is the simplest approach for a single‑user homelab. If you have multiple users, you might want auto or a custom mapping.

After that tweak, restart the daemon: