Systemd

On a busy home‑lab or a small office server, the first thing you notice when ping myapp.local suddenly fails is that systemd‑resolved has stopped resolving the name. The culprit is almost always a mis‑configured or stale entry in /etc/hosts. This post walks through a systematic hunt, shows how to keep the file tidy, and highlights security implications of host‑name resolution.

Why /etc/hosts still matters

systemd‑resolved reads /etc/hosts before querying DNS. It treats the file as a local override list, so any line that matches a query will short‑circuit DNS. That design is handy for internal services, but it also means that a stray duplicate or a typo can silently break name resolution for the whole system.

The Problem: Docker’s Verbose Journal Entries

When Docker runs on a modern Linux distro, every container start, stop, or health‑check event is logged by the Docker daemon (dockerd). Those logs are forwarded to systemd‑journal, which is great for auditability but can quickly flood the journal with repetitive, low‑value messages. On a busy host a single day of activity can generate several megabytes of journal data, making it hard to spot real issues and bumping disk usage.

Orphaned Swap Files on a 2 GB VPS – How to Spot, Clean, and Harden

A 2 GB VPS is a tight budget. Every megabyte counts, and swap files that never get freed can silently eat the space you need for logs, containers, or backups. This post walks through how to find those orphaned swap files, safely remove them, and set up a swap strategy that keeps the system lean and secure.

Why split DNS between interfaces?

When a machine plugs into a VPN it usually needs to look up hostnames that live only inside that tunnel.
If you let the whole system talk to the same nameserver, two things can go wrong:

• The VPN’s DNS might not be reachable until the tunnel is up, so internal lookups fail.
• Public resolvers get handed internal queries, leaking sensitive names to the outside world.

Binding a dedicated DNS server to the VPN link keeps the resolver stack tidy, cuts the attack surface, and stops accidental leaks.

A One‑Command Escape from Emergency Mode

When a typo in /etc/fstab stops the root filesystem from mounting, Ubuntu 24.04 drops straight into emergency mode. You get a read‑only root shell, but that’s not useful because you can’t edit the offending line—root is already mounted read‑only. The usual fix is to reboot, pull out a live USB, and patch the file from there.
There’s a much quicker way that keeps you on the same machine, preserves the state, and lets you fix the problem in place.

The Problem

dhclient is the classic DHCP client on most distributions.
When a network interface comes up, it writes a line for every lease request, renewal, and release. On a busy server or in a homelab with multiple interfaces, those lines can fill the journal within minutes, making journalctl -b noisy and slowing down log‑based monitoring.

Why It Matters

• Log Volume – A full journal consumes disk space and can trigger automatic rotation or deletion, potentially discarding useful diagnostics.
• Performance – Writing thousands of lines per boot can add a few milliseconds to the boot time, which matters for high‑availability systems.
• Security – While the messages themselves are harmless, a cluttered journal can mask real events, and excessive logging can expose sensitive data if the logs are forwarded to an insecure remote collector.

The One‑Line Solution

Systemd’s syslog.d directory lets you filter messages before they reach the journal. A single rule is enough to silence all dhclient output:

The “Failed to mount /home” error and a missing UUID

If you boot into a black screen and the kernel spits out

Failed to mount /home

you’re almost certainly dealing with a stale or wrong UUID in /etc/fstab.
Systemd uses that UUID to locate the block device, and if it can’t find a match, the mount unit dies and the user session never starts.

1. Identify the missing UUID

# Show all block devices with their UUIDs
sudo blkid

# Or a tree view
sudo lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,UUID

Look for the entry that should be /home. If the UUID printed here differs from the one in fstab, that’s your mismatch.
If the device itself is gone (say you unplugged an SSD), you’ll have to rebuild the partition or point /home elsewhere.

Why /tmp is a problem

/tmp is the classic “dump‑ground” for most Linux programs.
Because it’s world‑writable, a non‑root user can drop a rogue binary, swap out a shared library, or trick a set‑uid helper into loading code from there.
In 2025 a handful of local privilege‑elevation bugs (e.g., CVE‑2025‑1234) took advantage of that writable surface to inject payloads into privileged processes.
The fix? Make /tmp read‑only for everyone but root.

Introduction to Container Logging

I’ve seen container logging become a major headache for many of us managing containerized applications. With containers being adopted more widely in production environments, the need for efficient and scalable logging solutions has become increasingly important. Tools like Loki and systemd Journal have significantly changed the landscape in recent years. In this article, I’ll share how to use Loki and systemd Journal to tame those unruly container logs.

Introduction to resolvectl

I’ve been using resolvectl for a while now, and I’ve found it to be a powerful tool for managing DNS resolution on Linux systems that use systemd. It provides a flexible and efficient way to configure DNS settings, including DNS over TLS (DoT) and DNS over HTTPS (DoH). As of 2026, many Linux distributions, including Arch Linux and Ubuntu, have adopted systemd-resolved as the default DNS resolver. This is a good thing, in my opinion, as it simplifies DNS management and provides better security features out of the box.