Linux Café

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.

The Flicker Problem

I bought a 2022 Dell XPS 13 a few months ago and, like most people, I wanted to use an external 4K monitor via the single USB‑C port. The laptop ships with a Thunderbolt 4 controller that should handle 60 Hz 4K output without issue. On my Fedora 38 machine the monitor flickers when I connect it, and the flicker is worse on Wayland than on Xorg. The screen stutters every 1–2 seconds because the refresh rate drops in a periodic fashion. I spent a week trying to pin down the cause before finding a reliable fix.

USB plug‑in spam is a classic annoyance on modern Linux boxes. Every time you drop a keyboard, a mouse, or even a USB‑SD card in, the kernel goes into a burst‑mode and writes a wall of messages to journalctl. On a busy server or a home‑lab machine that logs everything, those lines can quickly fill the journal, slow down log‑rotation, and make it hard to spot real problems.

Below is a hands‑on guide to quiet those messages without losing the useful diagnostics you need. The techniques work on recent systemd‑based distributions (Debian 12, Ubuntu 24.04, Arch 2026, etc.) and are safe for a security‑aware setup because they only suppress noise, not real alerts.

I was running a little home‑lab server on a 2 GB SSD. The board was an Orange Pi Zero‑like single‑board computer, and it was juggling a personal web server, a GitLab instance, and a handful of containerised apps. After a month of steady traffic, the SSD hit 100 % on /var. The culprit? systemd‑journald had quietly gobbled up the whole drive.

journald is the default logger on most modern distros. It keeps logs in binary form under /var/log/journal. By default it will keep everything until the filesystem is full, then start deleting the oldest entries. On a tiny SSD that can happen faster than you can say “disk full”.

I’m ready to help polish the post, but I’ll need the article text first. Could you paste it here?