Systemd

Introduction to Slow Boot Issues

I’ve had my fair share of slow boot issues on Linux systems. Recently, I spent a significant amount of time troubleshooting a stubborn problem on one of my homelab machines. The system would take an inordinate amount of time to boot, and I couldn’t seem to pinpoint the cause. My first instinct was to use systemd-analyze blame to identify the culprit, but to my surprise, it didn’t provide any clear answers. I’ve seen this go wrong when the issue is more complex than a simple misconfigured service.

Introduction to systemd-resolved

I’ve been dealing with DNS lookup failures on my home network, and I’ve found that the systemd-resolved cache can be a major culprit. I’ve seen this go wrong when the cache becomes outdated or corrupted, leading to frustrating DNS lookup failures. In this article, I’ll share my experience with taming the systemd-resolved cache to fix these issues.

Understanding the systemd-resolved Cache

The real trick is to understand how the systemd-resolved cache works. It’s designed to improve DNS lookup performance by storing recent queries and their results. However, this cache can become outdated or corrupted, leading to DNS lookup failures. To get a better understanding of the cache, let’s take a look at the systemd-resolved configuration file, usually located at /etc/systemd/resolved.conf. You can view the file using the following command:

Introduction to Background Tasks

I’ve been running Linux servers in my homelab for years, and one thing that’s always come up is the need to run background tasks. These can be anything from simple scripts to complex applications, and they need to keep running even when I log out. I used to rely on tools like screen and tmux, but lately, I’ve been using nohup and systemd to simplify things.

Introduction to Background Jobs

I’ve lost count of how many times I’ve needed to run a command or script in the background, freeing up my terminal for other tasks. This is especially useful for long-running jobs like backups, downloads, or compilations. However, managing these background jobs can get messy, particularly when dealing with multiple processes or disconnections from the terminal. That’s where nohup and systemd come in - two essential tools for keeping your background jobs in check.

Introduction to systemd-resolved

I’ve seen this go wrong when working with Linux systems - systemd-resolved taking over your DNS settings without warning. As a Linux user, you’re likely familiar with the resolv.conf file, which contains the DNS resolver configuration for your system. However, with the introduction of systemd-resolved, things have changed. systemd-resolved is a systemd service that provides DNS resolution and caching, and it can sometimes override the settings in your resolv.conf file. In this article, we’ll explore how to tame systemd-resolved and prevent it from overriding your resolv.conf settings.

Introduction to systemd-resolved

I’ve spent years working with Linux, and one component that’s given me trouble is systemd-resolved, the DNS resolver service that comes bundled with systemd. Recently, I noticed my DNS queries were leaking, and I was getting annoying resolver errors on my Linux desktop. This prompted me to dive deeper into systemd-resolved and figure out how to tame it. I’ve seen this go wrong when people don’t take the time to understand how it works, so let’s start with the basics.

Introduction to journalctl Filtering

I’ve been using journalctl for years, and I’ve learned that it can be overwhelming if you don’t know how to filter the noise. By default, journalctl displays a vast amount of information that may not be relevant to your current needs. In this article, I’ll share how I tame the noise in journalctl using custom filters and priorities.

Understanding journalctl Basics

Before we dive into filtering, let’s cover some journalctl basics. The command journalctl is used to query the systemd journal, which stores log messages from various system components, including systemd services, kernel messages, and other system logs. I usually start with a simple command to view the most recent journal logs:

Introduction to Slow Boot Times

I’ve had my fair share of slow boot times on Linux. When I upgraded my desktop to the latest version of my distribution in 2025, I noticed some new systemd services that were slowing down my boot process. The real trick is identifying which services are causing the issue. After digging around, I found that some of these services weren’t essential for my daily usage, and disabling them made a significant difference.

Introduction to Container Logs

I’ve been running a homelab with various self-hosted services for a while now, and managing container logs has been a challenge. With containerization making it easy to spin up multiple containers, keeping track of their logs can be overwhelming. In my experience, using Podman and systemd-journald has been a game-changer for taming container logs.

What are Container Logs?

Container logs are essentially the output of a container’s stdout and stderr streams. They contain valuable information about the container’s execution, such as errors, warnings, and debug messages. By default, container logs are stored in the container’s filesystem, which can lead to log rotation issues and make it difficult to manage logs across multiple containers. I’ve seen this go wrong when logs start filling up the container’s disk space, causing all sorts of issues.

Introduction to DNS Troubles

I’ve been running my homelab for years, and one thing that still gets me is DNS troubles. Last year, I decided to set up systemd-resolved and dnsmasq to manage my home network’s DNS. The idea was to use systemd-resolved as the primary resolver and dnsmasq as a caching layer to improve performance. Sounds simple, but it didn’t quite work out that way.

Setting Up systemd-resolved

To start, I enabled systemd-resolved on my Ubuntu-based server. This involved editing the /etc/systemd/resolved.conf file to set the DNS servers and domains. I opted for Cloudflare’s DNS servers - they’re known for being fast and secure.