Linux Café

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 Log Noise

I’ve seen this go wrong when dealing with large systems - log files can quickly become overwhelming. In my experience, log noise is a significant issue, especially with the increasing complexity of systems and applications. Log noise refers to the irrelevant or redundant data in log files that can make it difficult to find the information you need. To tackle this, I usually start with jq and yq, two powerful command-line tools for parsing JSON and YAML data.

Introduction to DNS Resolution Issues

I’ve had my fair share of DNS resolution issues in my homelab over the years. Recently, I switched from using a single DNS resolver to a combination of Unbound and dnsmasq. This setup has been working well for me, but I’ve still encountered some issues that required troubleshooting. The real trick is identifying the root cause of the problem, which can be tricky.

Understanding Unbound and dnsmasq

Unbound is a recursive DNS resolver that provides a secure and private way to resolve domain names. It’s designed to be fast, efficient, and highly configurable. Dnsmasq, on the other hand, is a lightweight DNS forwarder and DHCP server. I’ve seen this go wrong when people don’t configure them correctly, so it’s essential to understand how they work together. In practice, using Unbound and dnsmasq together provides a good balance between security and performance.

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 Btrfs Send and Receive

I’ve been working with Btrfs for a while now, and I have to say, its send and receive functionality is one of my favorite features. It makes efficient backups and data replication across systems a breeze. However, like any complex operation, things can go wrong, and you’re left with incomplete or corrupted data. That’s where having a safety net like rsync comes in handy.

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 Podman Container Networking

I’ve been working with Podman for a while now, and I’ve found that networking issues can be a real pain point. When containers can’t communicate with each other or the host machine, it’s frustrating and can cause downtime. In this article, I’ll show you how to use the ss and nftables commands to troubleshoot Podman container networking issues.

Understanding Podman Networking

Before we dive into troubleshooting, it’s essential to understand how Podman handles networking. By default, Podman uses a bridge network, which allows containers to communicate with each other and the host machine. You can verify this by running podman network ls, which lists all available networks.