<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Systemd on Linux Security</title><link>https://linuxtransfer.com/tags/systemd/</link><description>Recent content in Systemd on Linux Security</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 09 Oct 2026 11:54:11 +0200</lastBuildDate><atom:link href="https://linuxtransfer.com/tags/systemd/index.xml" rel="self" type="application/rss+xml"/><item><title>Launch a temporary root process with `systemd‑run` instead of `sudo`</title><link>https://linuxtransfer.com/post/2026-10-09-launch-a-temporary-root-process-withsystemdru/</link><pubDate>Fri, 09 Oct 2026 11:54:11 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-10-09-launch-a-temporary-root-process-withsystemdru/</guid><description>&lt;h2 id="run-a-single-command-as-root-with-systemdrun">Run a single command as root with &lt;code>systemd‑run&lt;/code>&lt;/h2>
&lt;p>When you just need to fire up one command as root and then drop back, &lt;code>sudo&lt;/code> is the go‑to.&lt;br>
But if your distro already runs systemd, &lt;code>systemd‑run&lt;/code> can be a leaner, more isolated way to do it—especially for short‑lived tasks.&lt;/p>
&lt;h3 id="what-systemdrun-actually-does">What &lt;code>systemd‑run&lt;/code> actually does&lt;/h3>
&lt;p>&lt;code>systemd‑run&lt;/code> spawns a transient unit (either a &lt;em>scope&lt;/em> or a &lt;em>service&lt;/em>) that inherits the caller’s privileges and then elevates them to root when you add &lt;code>--user&lt;/code> or &lt;code>--scope&lt;/code> with &lt;code>--user&lt;/code>.&lt;br>
Unlike &lt;code>sudo&lt;/code>, the unit vanishes as soon as the command finishes, and you can sprinkle a handful of systemd properties on it to tighten the environment.&lt;/p></description></item><item><title>Fixing “Permission denied” on /tmp After a Kernel Update Removed the Sticky Bit</title><link>https://linuxtransfer.com/post/2026-09-30-fixing-permission-denied-on-tmp-after-a-kerne/</link><pubDate>Wed, 30 Sep 2026 11:22:30 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-09-30-fixing-permission-denied-on-tmp-after-a-kerne/</guid><description>&lt;h3 id="the-sticky-bit-in-a-nutshell">The sticky bit in a nutshell&lt;/h3>
&lt;p>The sticky bit (&lt;code>+t&lt;/code>) on a directory means that only the file’s owner, the directory’s owner, or root can delete or rename files inside it. &lt;code>/tmp&lt;/code> is traditionally set to &lt;code>1777&lt;/code> (octal) – owner &lt;code>root&lt;/code>, group &lt;code>root&lt;/code>, permissions &lt;code>rwxrwxrwt&lt;/code>. That lets any user create files, but stops them from messing with each other’s data.&lt;/p>
&lt;h3 id="what-happened-after-the-update">What happened after the update&lt;/h3>
&lt;p>Some kernel releases changed the default mount options for &lt;code>tmpfs&lt;/code> or how &lt;code>tmpfs&lt;/code>‑based &lt;code>/tmp&lt;/code> is handled. If &lt;code>/tmp&lt;/code> is mounted as &lt;code>tmpfs&lt;/code> without the sticky bit, the kernel quietly clears the &lt;code>+t&lt;/code> flag. The directory stays world‑writable, but the protection that stops users from deleting each other’s files disappears. Applications that expect the sticky bit now refuse to write, because they see the directory as insecure.&lt;/p></description></item><item><title>How to Get a Systemd Timer Back on Track After a Kernel Upgrade</title><link>https://linuxtransfer.com/post/2026-09-18-how-to-get-a-systemd-timer-back-on-track-afte/</link><pubDate>Fri, 18 Sep 2026 09:33:58 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-09-18-how-to-get-a-systemd-timer-back-on-track-afte/</guid><description>&lt;h2 id="systemd-timers-can-fall-silent-after-a-kernel-upgrade">Systemd timers can fall silent after a kernel upgrade&lt;/h2>
&lt;p>When a new kernel lands, the kernel‑specific modules and initramfs changes can
break the &lt;em>ExecStartPre&lt;/em> or &lt;em>ExecStart&lt;/em> scripts that a timer relies on.&lt;br>
The result? A timer that never fires, or that fires with the wrong environment.&lt;/p>
&lt;p>Below is a step‑by‑step guide to diagnose and restore a broken timer, with
security‑aware notes and trade‑offs you’ll run into in a production or homelab
setup.&lt;/p></description></item><item><title>Using journalctl to Track Down the Hidden ‘eth0’ Carrier Lost Messages That Cause Network Flaps After a Kernel Upgrade</title><link>https://linuxtransfer.com/post/2026-09-14-using-journalctl-to-track-down-the-hidden-eth/</link><pubDate>Mon, 14 Sep 2026 11:45:14 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-09-14-using-journalctl-to-track-down-the-hidden-eth/</guid><description>&lt;h2 id="when-a-kernel-upgrade-silently-breaks-your-network">When a kernel upgrade silently breaks your network&lt;/h2>
&lt;p>Kernel upgrades are usually painless, but on a few systems they can trigger a cascade of “carrier lost” messages that make the interface drop and come back up repeatedly. The messages are buried deep in the system journal, so you may not notice them until the network flaps start causing outages. This post shows how to locate those hidden messages with &lt;code>journalctl&lt;/code>, correlate them with real‑world symptoms, and apply a fix that keeps the interface stable.&lt;/p></description></item><item><title>Taming systemd Restart Policies to Prevent Service Deluge</title><link>https://linuxtransfer.com/post/2026-08-15-taming-systemd-restart-policies-to-prevent-se/</link><pubDate>Sat, 15 Aug 2026 08:22:06 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-08-15-taming-systemd-restart-policies-to-prevent-se/</guid><description>&lt;h2 id="introduction-to-systemd-restart-policies">Introduction to systemd Restart Policies&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when a service is misconfigured and ends up consuming all your system resources. Systemd is a core component of most modern Linux distributions, responsible for managing system services. One of its key features is the ability to automatically restart services that fail or exit unexpectedly. However, if not properly configured, this can lead to a &amp;ldquo;service deluge&amp;rdquo; where a failing service is repeatedly restarted.&lt;/p></description></item><item><title>Recovering from a Failed Boot: Using systemd's Emergency Mode and Rescue Shell to Troubleshoot Initramfs Issues</title><link>https://linuxtransfer.com/post/2026-08-13-recovering-from-a-failed-boot-using-systemds-/</link><pubDate>Thu, 13 Aug 2026 08:04:43 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-08-13-recovering-from-a-failed-boot-using-systemds-/</guid><description>&lt;h2 id="introduction-to-emergency-mode-and-rescue-shell">Introduction to Emergency Mode and Rescue Shell&lt;/h2>
&lt;p>When your Linux system fails to boot, it can be frustrating - especially if you&amp;rsquo;re not familiar with the troubleshooting process. I&amp;rsquo;ve seen this go wrong when people don&amp;rsquo;t know where to start. Luckily, systemd&amp;rsquo;s Emergency Mode and Rescue Shell are here to help. In this article, we&amp;rsquo;ll dive into how to use these tools to troubleshoot initramfs issues and get your system up and running again.&lt;/p></description></item><item><title>Taming Log Noise with journalctl: Filtering Out the Unimportant Stuff</title><link>https://linuxtransfer.com/post/2026-08-12-taming-log-noise-with-journalctl-filtering-ou/</link><pubDate>Wed, 12 Aug 2026 10:40:19 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-08-12-taming-log-noise-with-journalctl-filtering-ou/</guid><description>&lt;h2 id="introduction-to-log-noise">Introduction to Log Noise&lt;/h2>
&lt;p>When working with Linux systems, logs are an essential part of troubleshooting, monitoring, and maintaining the health of your system. However, with the vast amount of data being logged, it can become overwhelming to sift through the noise to find the important information. I&amp;rsquo;ve seen this go wrong when trying to debug a complex issue, only to get lost in a sea of irrelevant log messages. This is where &lt;code>journalctl&lt;/code> comes in, a powerful tool for managing and filtering system logs.&lt;/p></description></item><item><title>Troubleshooting systemd Service Restart Failures with Dependency Ordering and Retry Policies</title><link>https://linuxtransfer.com/post/2026-08-11-troubleshooting-systemd-service-restart-failu/</link><pubDate>Tue, 11 Aug 2026 10:39:09 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-08-11-troubleshooting-systemd-service-restart-failu/</guid><description>&lt;h2 id="introduction-to-systemd-service-restart-failures">Introduction to systemd Service Restart Failures&lt;/h2>
&lt;p>When working with Linux systems, especially those using systemd as the init system, service management is crucial for maintaining system stability and functionality. I&amp;rsquo;ve seen this go wrong when a service fails to restart properly, often due to dependency ordering issues or retry policy misconfigurations. Understanding how to troubleshoot and resolve these issues is essential for ensuring system reliability and uptime.&lt;/p>
&lt;h2 id="understanding-systemd-service-dependencies">Understanding systemd Service Dependencies&lt;/h2>
&lt;p>Systemd services can have complex dependencies, defined in their service files (typically located in &lt;code>/etc/systemd/system/&lt;/code> or &lt;code>/usr/lib/systemd/system/&lt;/code>). These dependencies are crucial for ensuring that services start in the correct order. For example, a web server might depend on the network service to be started before it can operate. Misconfigured dependencies can lead to services failing to start or restart. The real trick is to understand the startup sequence and identify potential bottlenecks.&lt;/p></description></item><item><title>Troubleshooting systemd Service Restart Loops with Dependency Ordering</title><link>https://linuxtransfer.com/post/2026-08-08-troubleshooting-systemd-service-restart-loops/</link><pubDate>Sat, 08 Aug 2026 11:01:52 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-08-08-troubleshooting-systemd-service-restart-loops/</guid><description>&lt;h2 id="introduction-to-systemd-service-restart-loops">Introduction to systemd Service Restart Loops&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when working with Linux systems: a service enters a restart loop, and it&amp;rsquo;s not immediately clear why. These loops occur when a service fails to start or restarts repeatedly, often due to dependency issues or configuration problems. In practice, identifying the root cause can be tricky, but there are some practical steps you can take to troubleshoot systemd service restart loops.&lt;/p></description></item><item><title>Using systemd to Manage and Rotate Log Files Without Running Out of Disk Space</title><link>https://linuxtransfer.com/post/2026-08-06-using-systemd-to-manage-and-rotate-log-files-/</link><pubDate>Thu, 06 Aug 2026 10:21:43 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-08-06-using-systemd-to-manage-and-rotate-log-files-/</guid><description>&lt;h2 id="introduction-to-log-rotation-with-systemd">Introduction to Log Rotation with systemd&lt;/h2>
&lt;p>I&amp;rsquo;ve seen log files consume all available disk space, bringing systems to a grinding halt. That&amp;rsquo;s why log rotation is a crucial aspect of system administration. With systemd becoming a de facto standard for managing system services and logs on many Linux distributions, I&amp;rsquo;ll explore how to use it to manage and rotate log files efficiently.&lt;/p>
&lt;h2 id="understanding-systemd-journald">Understanding systemd-journald&lt;/h2>
&lt;p>systemd-journald is the system service that collects and stores log messages from various sources, including system services, kernel messages, and user applications. By default, journald stores log messages in a binary format, which can be queried using the &lt;code>journalctl&lt;/code> command. To manage log rotation, we need to understand how journald handles log storage and rotation. Don&amp;rsquo;t bother with manually rotating log files - journald can handle it for you.&lt;/p></description></item><item><title>Taming systemd-resolved: Avoiding DNS Surprises on Multi-Network Linux Setups</title><link>https://linuxtransfer.com/post/2026-08-05-taming-systemd-resolved-avoiding-dns-surprise/</link><pubDate>Wed, 05 Aug 2026 08:04:38 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-08-05-taming-systemd-resolved-avoiding-dns-surprise/</guid><description>&lt;h2 id="introduction-to-systemd-resolved">Introduction to systemd-resolved&lt;/h2>
&lt;p>I&amp;rsquo;ve seen systemd-resolved cause some headaches in multi-network setups, so it&amp;rsquo;s worth understanding how it works. As part of the systemd suite, systemd-resolved is a DNS resolver that&amp;rsquo;s enabled by default on many modern Linux distributions, including Ubuntu and Fedora. The real trick is configuring it to avoid DNS surprises.&lt;/p>
&lt;h2 id="configuring-systemd-resolved">Configuring systemd-resolved&lt;/h2>
&lt;p>To get systemd-resolved working the way you want, you need to know how it uses DNS servers. It combines the DNS servers provided by your system&amp;rsquo;s network configuration with those specified in the &lt;code>/etc/systemd/resolved.conf&lt;/code> file. Don&amp;rsquo;t bother with the network configuration; just modify the &lt;code>resolved.conf&lt;/code> file to specify your preferred DNS servers. For example, to use Google&amp;rsquo;s public DNS servers, add the following lines to the &lt;code>[Resolve]&lt;/code> section:&lt;/p></description></item><item><title>Taming Log Noise with jq and systemd Journal Filters</title><link>https://linuxtransfer.com/post/2026-08-04-taming-log-noise-with-jq-and-systemd-journal-/</link><pubDate>Tue, 04 Aug 2026 10:28:50 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-08-04-taming-log-noise-with-jq-and-systemd-journal-/</guid><description>&lt;h2 id="introduction-to-log-noise">Introduction to Log Noise&lt;/h2>
&lt;p>I&amp;rsquo;ve seen log noise become a significant headache for Linux administrators, making it tough to identify important events and errors in system logs. With the sheer volume of data generated by modern systems, filtering out irrelevant information is crucial for efficient troubleshooting and maintenance. In this article, I&amp;rsquo;ll show you how to tame log noise using &lt;code>jq&lt;/code> and systemd journal filters.&lt;/p>
&lt;h2 id="understanding-systemd-journal">Understanding systemd Journal&lt;/h2>
&lt;p>The systemd journal is a centralized logging solution that collects and stores log messages from various system components. It&amp;rsquo;s a robust and efficient way to manage logs, allowing administrators to filter, prioritize, and analyze log data. The journal stores log messages in a binary format, which can be queried and filtered using the &lt;code>journalctl&lt;/code> command. Don&amp;rsquo;t bother with trying to parse the binary format directly - it&amp;rsquo;s not worth the hassle.&lt;/p></description></item><item><title>Using resolvectl to Diagnose and Resolve Stubborn DNS Issues on Linux</title><link>https://linuxtransfer.com/post/2026-08-03-using-resolvectl-to-diagnose-and-resolve-stub/</link><pubDate>Mon, 03 Aug 2026 11:32:32 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-08-03-using-resolvectl-to-diagnose-and-resolve-stub/</guid><description>&lt;h2 id="introduction-to-resolvectl">Introduction to resolvectl&lt;/h2>
&lt;p>I&amp;rsquo;ve seen my fair share of DNS issues on Linux, and one tool that&amp;rsquo;s always helped me resolve them is &lt;code>resolvectl&lt;/code>. This command-line utility, part of the systemd suite, provides a comprehensive way to query and configure DNS settings on your system. In this article, I&amp;rsquo;ll share some practical examples of how to use &lt;code>resolvectl&lt;/code> to diagnose and fix stubborn DNS issues.&lt;/p>
&lt;h2 id="understanding-dns-resolution">Understanding DNS Resolution&lt;/h2>
&lt;p>Before diving into &lt;code>resolvectl&lt;/code>, it&amp;rsquo;s essential to understand how DNS resolution works on Linux. The DNS (Domain Name System) is responsible for translating human-readable domain names into IP addresses that computers can understand. On Linux systems, DNS resolution is typically handled by a resolver, which queries DNS servers to resolve domain names. The resolver configuration is usually defined in &lt;code>/etc/resolv.conf&lt;/code>, but with systemd, &lt;code>resolvectl&lt;/code> offers a more integrated and dynamic way to manage DNS settings.&lt;/p></description></item><item><title>Taming Systemd Service Restart Policies to Prevent Cascading Failures</title><link>https://linuxtransfer.com/post/2026-07-30-taming-systemd-service-restart-policies-to-pr/</link><pubDate>Thu, 30 Jul 2026 11:07:07 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-30-taming-systemd-service-restart-policies-to-pr/</guid><description>&lt;h2 id="introduction-to-systemd-service-restart-policies">Introduction to Systemd Service Restart Policies&lt;/h2>
&lt;p>Systemd is the backbone of most modern Linux distributions, and one of its key features is managing service restart policies. I&amp;rsquo;ve seen this go wrong when a service fails and takes down the entire system with it. In this article, we&amp;rsquo;ll dive into the world of systemd service restart policies and explore how to configure them to prevent cascading failures.&lt;/p>
&lt;h2 id="understanding-systemd-service-restart-policies">Understanding Systemd Service Restart Policies&lt;/h2>
&lt;p>Systemd provides several restart policies that can be applied to services. The real trick is understanding when to use each one:&lt;/p></description></item><item><title>Taming Log Noise with jq and systemd Journal Filters</title><link>https://linuxtransfer.com/post/2026-07-29-taming-log-noise-with-jq-and-systemd-journal-/</link><pubDate>Wed, 29 Jul 2026 11:23:22 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-29-taming-log-noise-with-jq-and-systemd-journal-/</guid><description>&lt;h2 id="introduction-to-log-noise">Introduction to Log Noise&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when dealing with system logs - the sheer amount of unnecessary or redundant log messages can make it difficult to identify real issues. As a Linux administrator, managing log noise is essential for efficient system maintenance and troubleshooting. In this article, I&amp;rsquo;ll share how to tame log noise using &lt;code>jq&lt;/code> and systemd journal filters.&lt;/p>
&lt;h2 id="understanding-systemd-journal">Understanding systemd Journal&lt;/h2>
&lt;p>Systemd journal is a powerful centralized logging system that collects and stores log messages from various system components. It provides a robust and flexible way to manage logs, including filtering, prioritization, and storage. The real trick is to leverage the &lt;code>journalctl&lt;/code> command to work with systemd journal.&lt;/p></description></item><item><title>Taming log Noise with journalctl: Filtering Out the Chaff to Find Meaningful Errors</title><link>https://linuxtransfer.com/post/2026-07-28-taming-log-noise-with-journalctl-filtering-ou/</link><pubDate>Tue, 28 Jul 2026 08:12:37 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-28-taming-log-noise-with-journalctl-filtering-ou/</guid><description>&lt;h2 id="introduction-to-journalctl">Introduction to Journalctl&lt;/h2>
&lt;p>I&amp;rsquo;ve been working with Linux systems for years, and one tool that&amp;rsquo;s become essential to my workflow is journalctl. As of 2026, most modern Linux distributions have adopted systemd as their default init system, making journalctl a must-know tool for system administrators and users alike. In this article, I&amp;rsquo;ll share how to use journalctl to filter out unnecessary log noise and focus on meaningful errors.&lt;/p>
&lt;h2 id="understanding-journalctl-basics">Understanding Journalctl Basics&lt;/h2>
&lt;p>Before diving into advanced filtering techniques, let&amp;rsquo;s cover the basics of journalctl. The command &lt;code>journalctl&lt;/code> can be used to view system logs, and by default, it will show you the most recent log entries. You can use the &lt;code>-n&lt;/code> option to specify the number of log entries to display, for example, &lt;code>journalctl -n 10&lt;/code> will show you the last 10 log entries. Don&amp;rsquo;t bother with &lt;code>sudo&lt;/code> unless you need to access system logs - journalctl will automatically use your current user&amp;rsquo;s permissions.&lt;/p></description></item><item><title>Debugging Connectivity Issues with resolvectl and ss: A Step-by-Step Guide to Identifying DNS and Routing Problems</title><link>https://linuxtransfer.com/post/2026-07-25-debugging-connectivity-issues-with-resolvectl/</link><pubDate>Sat, 25 Jul 2026 11:18:34 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-25-debugging-connectivity-issues-with-resolvectl/</guid><description>&lt;h2 id="introduction-to-debugging-connectivity-issues">Introduction to Debugging Connectivity Issues&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when dealing with connectivity issues on Linux systems: not knowing where to start. Two essential tools can save you a lot of time - &lt;code>resolvectl&lt;/code> and &lt;code>ss&lt;/code>. These tools help in identifying and troubleshooting DNS and routing problems. Let&amp;rsquo;s dive into a step-by-step guide on how to use them, focusing on practical examples and security considerations where relevant.&lt;/p>
&lt;h2 id="understanding-resolvectl">Understanding resolvectl&lt;/h2>
&lt;p>&lt;code>resolvectl&lt;/code> is a command-line utility provided by systemd for querying and configuring the DNS resolver. It&amp;rsquo;s incredibly useful for controlling the DNS resolver, including setting DNS servers, querying the DNS cache, and configuring DNS over TLS (DoT) or DNS over HTTPS (DoH). To get started with &lt;code>resolvectl&lt;/code>, you can use the following command to status the current DNS configuration:&lt;/p></description></item><item><title>Taming systemd Service Restart Policies to Prevent Unexpected Downtime</title><link>https://linuxtransfer.com/post/2026-07-22-taming-systemd-service-restart-policies-to-pr/</link><pubDate>Wed, 22 Jul 2026 10:33:24 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-22-taming-systemd-service-restart-policies-to-pr/</guid><description>&lt;h2 id="introduction-to-systemd-service-restart-policies">Introduction to systemd Service Restart Policies&lt;/h2>
&lt;p>I&amp;rsquo;ve seen many Linux systems go down due to poorly configured service restart policies. Systemd, being the core component of most modern Linux distributions, provides a robust way to manage system services, including their startup, runtime, and shutdown. One of the key features of systemd is its ability to manage service restart policies, which dictate how services should be handled in case of failures or crashes.&lt;/p></description></item><item><title>Taming Log Noise with journalctl: Filtering Out the Usual Suspects to Find Real Issues</title><link>https://linuxtransfer.com/post/2026-07-21-taming-log-noise-with-journalctl-filtering-ou/</link><pubDate>Tue, 21 Jul 2026 11:01:50 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-21-taming-log-noise-with-journalctl-filtering-ou/</guid><description>&lt;h2 id="introduction-to-log-noise">Introduction to Log Noise&lt;/h2>
&lt;p>I&amp;rsquo;ve seen log noise become a significant issue for Linux administrators, making it tough to identify real problems in system logs. With the sheer amount of data generated by various system components, it&amp;rsquo;s easy to get lost. To tackle this, I usually start with &lt;code>journalctl&lt;/code>, a powerful command-line utility that allows you to view and manage system logs. It&amp;rsquo;s part of the systemd suite and provides a flexible way to filter, prioritize, and analyze log messages.&lt;/p></description></item><item><title>Resolving DNS Quirks with systemd-resolved and Split DNSConfigs</title><link>https://linuxtransfer.com/post/2026-07-19-resolving-dns-quirks-with-systemd-resolved-an/</link><pubDate>Sun, 19 Jul 2026 09:59:52 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-19-resolving-dns-quirks-with-systemd-resolved-an/</guid><description>&lt;h2 id="introduction-to-dns-quirks-and-systemd-resolved">Introduction to DNS Quirks and systemd-resolved&lt;/h2>
&lt;p>I&amp;rsquo;ve seen my fair share of DNS issues over the years, and in complex network environments, they can become a real headache. These problems often stem from misconfigured DNS servers, conflicting resolver settings, or the challenges of managing split DNS configurations. With &lt;code>systemd-resolved&lt;/code>, managing DNS resolution has become more robust and secure. I&amp;rsquo;ve found it to be an essential tool in my Linux toolkit.&lt;/p></description></item><item><title>Taming Log Noise with jq and systemd Journal Filters</title><link>https://linuxtransfer.com/post/2026-07-18-taming-log-noise-with-jq-and-systemd-journal-/</link><pubDate>Sat, 18 Jul 2026 11:16:41 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-18-taming-log-noise-with-jq-and-systemd-journal-/</guid><description>&lt;h2 id="introduction-to-log-noise-reduction">Introduction to Log Noise Reduction&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when working with Linux systems: log noise can be a significant issue, making it difficult to identify and troubleshoot problems. Log noise refers to the excessive amount of log data that is not relevant to the issue at hand. With the increasing complexity of systems, managing log noise has become crucial for efficient system administration. This is where people usually get burned - trying to sift through a sea of irrelevant log messages. The real trick is to use the right tools to tame log noise, and that&amp;rsquo;s where &lt;code>jq&lt;/code> and systemd journal filters come in.&lt;/p></description></item><item><title>Taming Log Noise with systemd Journal Filters and Grep</title><link>https://linuxtransfer.com/post/2026-07-16-taming-log-noise-with-systemd-journal-filters/</link><pubDate>Thu, 16 Jul 2026 09:20:19 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-16-taming-log-noise-with-systemd-journal-filters/</guid><description>&lt;h2 id="introduction-to-log-noise">Introduction to Log Noise&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when log noise gets out of hand - it&amp;rsquo;s like trying to find a needle in a haystack. As a Linux administrator, managing log noise is crucial for efficient system maintenance and debugging. In this article, we&amp;rsquo;ll explore how to tame log noise using systemd journal filters and grep.&lt;/p>
&lt;h2 id="understanding-systemd-journal">Understanding Systemd Journal&lt;/h2>
&lt;p>Systemd journal is a centralized logging system that collects log messages from various system components, including systemd services, kernel messages, and application logs. The journal stores log messages in a binary format, which can be queried and filtered using the &lt;code>journalctl&lt;/code> command. To view all log messages, you can use the following command:&lt;/p></description></item><item><title>Using resolvectl to Fix DNS Leaks and Improve Linux Network Privacy</title><link>https://linuxtransfer.com/post/2026-07-15-using-resolvectl-to-fix-dns-leaks-and-improve/</link><pubDate>Wed, 15 Jul 2026 08:20:33 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-15-using-resolvectl-to-fix-dns-leaks-and-improve/</guid><description>&lt;h2 id="introduction-to-resolvectl">Introduction to resolvectl&lt;/h2>
&lt;p>I&amp;rsquo;ve seen DNS leaks compromise network privacy time and again, so I&amp;rsquo;m always on the lookout for ways to tighten up my DNS configuration. As a Linux user, you&amp;rsquo;re likely familiar with the importance of DNS resolution for accessing websites and services. &lt;code>resolvectl&lt;/code> is a powerful tool that comes with systemd, and it&amp;rsquo;s been a game-changer for managing DNS resolution on my systems.&lt;/p>
&lt;h2 id="what-is-resolvectl">What is resolvectl?&lt;/h2>
&lt;p>&lt;code>resolvectl&lt;/code> is a command-line utility that allows you to control and configure DNS resolution on your system. It&amp;rsquo;s part of the systemd suite, which is widely used on modern Linux distributions. With &lt;code>resolvectl&lt;/code>, you can set DNS servers, query DNS records, and troubleshoot DNS issues - all from the comfort of your terminal.&lt;/p></description></item><item><title>Troubleshooting Disk Usage Issues with btrfs Snapshots and systemd Timers</title><link>https://linuxtransfer.com/post/2026-07-14-troubleshooting-disk-usage-issues-with-btrfs-/</link><pubDate>Tue, 14 Jul 2026 08:58:49 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-14-troubleshooting-disk-usage-issues-with-btrfs-/</guid><description>&lt;h2 id="introduction-to-btrfs-snapshots-and-systemd-timers">Introduction to btrfs Snapshots and systemd Timers&lt;/h2>
&lt;p>As someone who&amp;rsquo;s been running Linux systems for years, I&amp;rsquo;ve learned that managing disk usage and ensuring data integrity are crucial tasks. One effective way to achieve this is by utilizing btrfs snapshots and systemd timers. I&amp;rsquo;ve seen this go wrong when people don&amp;rsquo;t have a solid backup strategy in place, so it&amp;rsquo;s worth taking the time to set up. btrfs, a modern file system, offers advanced features like snapshotting, which allows you to create a read-only copy of your file system at a particular point in time. When combined with systemd timers, you can automate the creation and management of these snapshots, making it easier to troubleshoot disk usage issues and maintain a healthy system.&lt;/p></description></item><item><title>Using resolvectl to Debug Stubborn DNS Resolution Issues on Linux</title><link>https://linuxtransfer.com/post/2026-07-12-using-resolvectl-to-debug-stubborn-dns-resolu/</link><pubDate>Sun, 12 Jul 2026 08:51:43 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-12-using-resolvectl-to-debug-stubborn-dns-resolu/</guid><description>&lt;h2 id="introduction-to-resolvectl">Introduction to resolvectl&lt;/h2>
&lt;p>I&amp;rsquo;ve seen my fair share of DNS resolution issues on Linux, and one tool that&amp;rsquo;s always been a lifesaver is &lt;code>resolvectl&lt;/code>. This command-line utility is part of the systemd suite, providing a comprehensive way to query and configure DNS settings on your system. When dealing with stubborn DNS problems, &lt;code>resolvectl&lt;/code> is often the first tool I reach for. In this article, we&amp;rsquo;ll delve into its practical uses for debugging DNS issues, exploring its capabilities, and discussing how it can be used with other tools for a more robust troubleshooting experience.&lt;/p></description></item><item><title>Using systemd-resolved to Tame DNS Lookup Surprises on Multi-Homed Linux Machines</title><link>https://linuxtransfer.com/post/2026-07-11-using-systemd-resolved-to-tame-dns-lookup-sur/</link><pubDate>Sat, 11 Jul 2026 08:24:10 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-11-using-systemd-resolved-to-tame-dns-lookup-sur/</guid><description>&lt;h2 id="introduction-to-systemd-resolved">Introduction to systemd-resolved&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when working with multi-homed Linux machines: DNS lookup surprises can be a real pain. A multi-homed machine, with multiple network interfaces each connected to a different network, can lead to DNS resolution problems. The system may not know which interface to use for DNS lookups, causing all sorts of issues. This is where people usually get burned - trying to troubleshoot DNS problems without a clear understanding of how their system is configured. To address this issue, I usually start with systemd-resolved, a tool that can help manage DNS resolution and provide more predictable behavior.&lt;/p></description></item><item><title>Troubleshooting DNS Leaks with systemd-resolved and resolv.conf</title><link>https://linuxtransfer.com/post/2026-07-09-troubleshooting-dns-leaks-with-systemd-resolv/</link><pubDate>Thu, 09 Jul 2026 08:15:21 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-09-troubleshooting-dns-leaks-with-systemd-resolv/</guid><description>&lt;h2 id="introduction-to-dns-leaks">Introduction to DNS Leaks&lt;/h2>
&lt;p>I&amp;rsquo;ve seen DNS leaks become a major concern for Linux users, especially those relying on systemd-resolved. A DNS leak occurs when your system sends DNS queries to an unintended DNS server, potentially exposing your browsing history and other sensitive information. In this article, I&amp;rsquo;ll share my experience and insights on how to identify and troubleshoot DNS leaks using systemd-resolved and resolv.conf.&lt;/p>
&lt;h2 id="understanding-systemd-resolved">Understanding systemd-resolved&lt;/h2>
&lt;p>Systemd-resolved is a powerful tool that provides DNS resolution. It acts as a local DNS resolver, caching DNS queries and responses to improve performance. By default, systemd-resolved uses the DNS servers provided by your network configuration, but you can configure it to use specific DNS servers. To check the current DNS servers used by systemd-resolved, run:&lt;/p></description></item><item><title>Extracting Valuable Data from Systemd Journal Logs with jq and grep</title><link>https://linuxtransfer.com/post/2026-07-08-extracting-valuable-data-from-systemd-journal/</link><pubDate>Wed, 08 Jul 2026 09:39:13 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-08-extracting-valuable-data-from-systemd-journal/</guid><description>&lt;h2 id="introduction-to-systemd-journal-logs">Introduction to Systemd Journal Logs&lt;/h2>
&lt;p>I&amp;rsquo;ve worked with Linux systems for years, and one of the most powerful tools at my disposal is systemd journal logs. These logs provide a centralized location for logging system events, making it easier to troubleshoot and diagnose issues. By default, systemd stores these logs in a binary format, which can make them a bit tricky to parse and analyze. However, with the help of tools like &lt;code>jq&lt;/code> and &lt;code>grep&lt;/code>, you can extract valuable data from these logs.&lt;/p></description></item><item><title>Troubleshooting Slow systemd Service Restarts with systemd-analyze</title><link>https://linuxtransfer.com/post/2026-07-05-troubleshooting-slow-systemd-service-restarts/</link><pubDate>Sun, 05 Jul 2026 10:06:58 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-05-troubleshooting-slow-systemd-service-restarts/</guid><description>&lt;h2 id="introduction-to-systemd-analyze">Introduction to systemd-analyze&lt;/h2>
&lt;p>I&amp;rsquo;ve seen my fair share of slow service restarts on Linux systems, and troubleshooting them can be a real challenge. That&amp;rsquo;s where systemd-analyze comes in - a powerful tool that helps analyze and troubleshoot systemd services. In this article, I&amp;rsquo;ll share how to use systemd-analyze to identify and potentially fix issues related to slow systemd service restarts.&lt;/p>
&lt;h2 id="understanding-systemd-analyze">Understanding systemd-analyze&lt;/h2>
&lt;p>The real trick is to understand what systemd-analyze can do for you. It&amp;rsquo;s a command-line tool that comes bundled with systemd, providing detailed information about the boot process, services, and their dependencies. With systemd-analyze, you can identify performance bottlenecks, slow services, and even issues with the system&amp;rsquo;s boot process. Don&amp;rsquo;t bother with manual logging and debugging - systemd-analyze can save you a lot of time and effort.&lt;/p></description></item><item><title>Resolving the "Unknown Host" Headache: Troubleshooting DNS Issues with systemd-resolved and resolv.conf</title><link>https://linuxtransfer.com/post/2026-07-01-resolving-the-unknown-host-headache-troublesh/</link><pubDate>Wed, 01 Jul 2026 09:38:07 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-07-01-resolving-the-unknown-host-headache-troublesh/</guid><description>&lt;h2 id="introduction-to-dns-troubleshooting">Introduction to DNS Troubleshooting&lt;/h2>
&lt;p>We&amp;rsquo;ve all been there - trying to access a website or service, only to be met with an &amp;ldquo;Unknown Host&amp;rdquo; error. These errors often stem from DNS issues, which can be frustrating to troubleshoot, especially when you&amp;rsquo;re not sure where to start. In my experience, the culprits are usually misconfigured &lt;code>resolv.conf&lt;/code> files or problems with &lt;code>systemd-resolved&lt;/code>. In this article, I&amp;rsquo;ll walk you through the practical aspects of troubleshooting DNS issues, focusing on &lt;code>systemd-resolved&lt;/code> and &lt;code>resolv.conf&lt;/code>, to help you resolve the &amp;ldquo;Unknown Host&amp;rdquo; headache efficiently.&lt;/p></description></item><item><title>Troubleshooting Btrfs Snapshot Overfill with systemd Timers and Log Rotation</title><link>https://linuxtransfer.com/post/2026-06-30-troubleshooting-btrfs-snapshot-overfill-with-/</link><pubDate>Tue, 30 Jun 2026 09:01:31 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-30-troubleshooting-btrfs-snapshot-overfill-with-/</guid><description>&lt;h2 id="introduction-to-btrfs-snapshots">Introduction to Btrfs Snapshots&lt;/h2>
&lt;p>I&amp;rsquo;ve worked with Btrfs for years, and its snapshot feature is one of my favorites. It allows you to create a read-only copy of a subvolume at a particular point in time, which is super useful for backups, testing, and rolling back changes. However, managing these snapshots can become a real pain, especially when dealing with a large number of them. In this article, I&amp;rsquo;ll show you how to troubleshoot Btrfs snapshot overfill issues using systemd timers and log rotation.&lt;/p></description></item><item><title>Troubleshooting Systemd Service Boot Delays with systemd-analyze</title><link>https://linuxtransfer.com/post/2026-06-29-troubleshooting-systemd-service-boot-delays-w/</link><pubDate>Mon, 29 Jun 2026 09:10:15 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-29-troubleshooting-systemd-service-boot-delays-w/</guid><description>&lt;h2 id="introduction-to-systemd-service-boot-delays">Introduction to Systemd Service Boot Delays&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when working with Linux systems managed by systemd - boot delays can be frustrating and impact system performance. In my experience, understanding how to troubleshoot these delays is crucial for maintaining efficient and reliable systems. Many Linux distributions, including Debian, Arch Linux, and OpenSUSE, rely on systemd for service management, so it&amp;rsquo;s essential to know how to use &lt;code>systemd-analyze&lt;/code> to identify and resolve boot delays caused by systemd services.&lt;/p></description></item><item><title>Taming Log Rotation: Preventing Disk Space Issues with systemd-journald and Log File Management</title><link>https://linuxtransfer.com/post/2026-06-24-taming-log-rotation-preventing-disk-space-iss/</link><pubDate>Wed, 24 Jun 2026 11:55:31 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-24-taming-log-rotation-preventing-disk-space-iss/</guid><description>&lt;h2 id="introduction-to-log-rotation">Introduction to Log Rotation&lt;/h2>
&lt;p>Log rotation - it&amp;rsquo;s one of those tasks that&amp;rsquo;s easy to overlook, but can quickly become a major headache if you don&amp;rsquo;t stay on top of it. I&amp;rsquo;ve seen this go wrong when log files consume all the available disk space, bringing a system to its knees. With many Linux distributions now using &lt;code>systemd-journald&lt;/code> as the default logging mechanism, understanding how to manage log rotation is more important than ever.&lt;/p></description></item><item><title>Taming systemd Service Restart Behavior: When to Use Restart, Retry, and Timeout Options</title><link>https://linuxtransfer.com/post/2026-06-22-taming-systemd-service-restart-behavior-when-/</link><pubDate>Mon, 22 Jun 2026 09:07:35 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-22-taming-systemd-service-restart-behavior-when-/</guid><description>&lt;h2 id="introduction-to-systemd-service-restart-behavior">Introduction to systemd Service Restart Behavior&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when a service is not properly configured - systemd, the core component of most modern Linux distributions, is responsible for managing system services. One of its key features is the ability to automatically restart services that fail or terminate unexpectedly, controlled by the &lt;code>Restart&lt;/code> directive in the service unit file. However, I&amp;rsquo;ve found that the &lt;code>Restart&lt;/code> directive alone may not be sufficient to handle all scenarios, which is where the &lt;code>Retry&lt;/code> and &lt;code>Timeout&lt;/code> options come into play.&lt;/p></description></item><item><title>Using systemd-resolved with Multiple DNS Servers and Split Horizon DNS</title><link>https://linuxtransfer.com/post/2026-06-20-using-systemd-resolved-with-multiple-dns-serv/</link><pubDate>Sat, 20 Jun 2026 08:55:08 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-20-using-systemd-resolved-with-multiple-dns-serv/</guid><description>&lt;h2 id="introduction-to-systemd-resolved">Introduction to systemd-resolved&lt;/h2>
&lt;p>I&amp;rsquo;ve been using systemd-resolved for a while now, and I have to say, it&amp;rsquo;s a game-changer when it comes to managing DNS resolution on Linux systems. As of 2026, it&amp;rsquo;s become a crucial component in many Linux distributions, including Ubuntu, Debian, and Fedora. In this article, I&amp;rsquo;ll walk you through how to use systemd-resolved with multiple DNS servers and split horizon DNS, including some practical examples and troubleshooting notes.&lt;/p></description></item><item><title>Taming systemd Restart Policies to Prevent Service Chaos</title><link>https://linuxtransfer.com/post/2026-06-18-taming-systemd-restart-policies-to-prevent-se/</link><pubDate>Thu, 18 Jun 2026 10:48:52 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-18-taming-systemd-restart-policies-to-prevent-se/</guid><description>&lt;h2 id="introduction-to-systemd-restart-policies">Introduction to systemd Restart Policies&lt;/h2>
&lt;p>I&amp;rsquo;ve seen systemd restart policies go wrong when not properly configured, leading to a never-ending cycle of restarts without resolving the underlying issue. To avoid this chaos, it&amp;rsquo;s essential to understand how systemd manages system services, including starting, stopping, and restarting them as needed. The key to taming these restart policies lies in understanding how systemd service files work and how to configure them effectively.&lt;/p></description></item><item><title>Troubleshooting DNS Leaks with systemd-resolved and resolv.conf</title><link>https://linuxtransfer.com/post/2026-06-16-troubleshooting-dns-leaks-with-systemd-resolv/</link><pubDate>Tue, 16 Jun 2026 10:58:16 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-16-troubleshooting-dns-leaks-with-systemd-resolv/</guid><description>&lt;h2 id="introduction-to-dns-leaks">Introduction to DNS Leaks&lt;/h2>
&lt;p>I&amp;rsquo;ve seen DNS leaks become a major concern for Linux users who care about their online privacy. Essentially, a DNS leak happens when your system&amp;rsquo;s DNS queries slip outside a secure tunnel - think VPN - and potentially expose your browsing history to prying eyes. Given the current online security landscape, being able to troubleshoot these leaks is more important than ever.&lt;/p>
&lt;h2 id="understanding-systemd-resolved">Understanding systemd-resolved&lt;/h2>
&lt;p>Systemd-resolved is a key system service in Linux that handles DNS resolution. It&amp;rsquo;s part of the systemd suite and is widely used in modern distributions like Ubuntu, Debian, and Fedora. One of the benefits of systemd-resolved is that it can be configured to use DNS over TLS (DoT) or DNS over HTTPS (DoH), which encrypts DNS queries and reduces the risk of leaks.&lt;/p></description></item><item><title>Resolving DNS Issues with resolvectl and systemd-resolved in a Home Network</title><link>https://linuxtransfer.com/post/2026-06-15-resolving-dns-issues-with-resolvectl-and-syst/</link><pubDate>Mon, 15 Jun 2026 09:54:03 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-15-resolving-dns-issues-with-resolvectl-and-syst/</guid><description>&lt;h2 id="introduction-to-dns-resolution">Introduction to DNS Resolution&lt;/h2>
&lt;p>When setting up a home network, DNS resolution is one of those critical components that can be a real pain to troubleshoot. I&amp;rsquo;ve seen this go wrong when people are new to Linux, so let&amp;rsquo;s dive into how to use &lt;code>resolvectl&lt;/code> to resolve DNS issues with &lt;code>systemd-resolved&lt;/code>.&lt;/p>
&lt;h2 id="understanding-systemd-resolved">Understanding systemd-resolved&lt;/h2>
&lt;p>&lt;code>systemd-resolved&lt;/code> is a system service that handles DNS resolution, among other network-related tasks. It&amp;rsquo;s part of the systemd suite and is widely used in many Linux distributions, including Ubuntu, Debian, and Fedora. The real trick is that &lt;code>systemd-resolved&lt;/code> provides improved DNS security and better support for modern DNS protocols like DNS over TLS (DoT) and DNS over HTTPS (DoH). Don&amp;rsquo;t bother with trying to use it without understanding these benefits, as they&amp;rsquo;re a key part of what makes &lt;code>systemd-resolved&lt;/code> so useful.&lt;/p></description></item><item><title>Troubleshooting Slow Network Connectivity with ss and resolvectl on Linux</title><link>https://linuxtransfer.com/post/2026-06-14-troubleshooting-slow-network-connectivity-wit/</link><pubDate>Sun, 14 Jun 2026 08:16:06 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-14-troubleshooting-slow-network-connectivity-wit/</guid><description>&lt;h2 id="introduction-to-network-troubleshooting">Introduction to Network Troubleshooting&lt;/h2>
&lt;p>I&amp;rsquo;ve seen my fair share of slow network connectivity issues on Linux, and having the right tools at your disposal can make all the difference. Two tools that I rely on are &lt;code>ss&lt;/code> and &lt;code>resolvectl&lt;/code>, which can help you diagnose and troubleshoot network issues. In this article, we&amp;rsquo;ll explore how to use these tools to identify and potentially fix slow network connectivity problems.&lt;/p>
&lt;h2 id="understanding-ss">Understanding &lt;code>ss&lt;/code>&lt;/h2>
&lt;p>The &lt;code>ss&lt;/code> command is a replacement for the traditional &lt;code>netstat&lt;/code> command, and it provides more detailed information about network connections, including TCP, UDP, and Unix domain sockets. To get started with &lt;code>ss&lt;/code>, you can use the following command to display all active connections:&lt;/p></description></item><item><title>Taming Disk-Hungry Logs with systemd's Persistent Journal and Log Rotation</title><link>https://linuxtransfer.com/post/2026-06-13-taming-disk-hungry-logs-with-systemds-persist/</link><pubDate>Sat, 13 Jun 2026 11:46:55 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-13-taming-disk-hungry-logs-with-systemds-persist/</guid><description>&lt;h2 id="introduction-to-log-management">Introduction to Log Management&lt;/h2>
&lt;p>I&amp;rsquo;ve seen log management become a major headache for many Linux administrators. Logs are essential for diagnosing issues, detecting security threats, and optimizing system performance, but they can grow rapidly and consume significant disk space. In practice, this can lead to performance issues and even system crashes. To avoid this, we can use systemd&amp;rsquo;s persistent journal and log rotation features.&lt;/p>
&lt;h2 id="understanding-systemds-journal">Understanding systemd&amp;rsquo;s Journal&lt;/h2>
&lt;p>Systemd&amp;rsquo;s journal is a centralized logging system that collects log messages from various system components, including systemd services, kernel messages, and application logs. The real trick is to configure it to use persistent storage, so logs aren&amp;rsquo;t lost upon system reboot. By default, the journal stores log messages in a volatile storage area, which isn&amp;rsquo;t very useful for long-term log management.&lt;/p></description></item><item><title>Using systemd to Manage and Rotate Logs for Forgotten System Services</title><link>https://linuxtransfer.com/post/2026-06-12-using-systemd-to-manage-and-rotate-logs-for-f/</link><pubDate>Fri, 12 Jun 2026 08:50:25 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-12-using-systemd-to-manage-and-rotate-logs-for-f/</guid><description>&lt;h2 id="introduction-to-log-management-with-systemd">Introduction to Log Management with systemd&lt;/h2>
&lt;p>I&amp;rsquo;ve seen many Linux admins struggle with log management, especially when it comes to system services that are often overlooked. Systemd is a powerful system and service manager that provides a wide range of features, including process management, dependency handling, and log management. In this article, I&amp;rsquo;ll focus on using systemd to manage and rotate logs for system services.&lt;/p>
&lt;h2 id="understanding-systemd-logs">Understanding systemd Logs&lt;/h2>
&lt;p>The real trick is to understand how systemd logs work. Systemd logs are stored in a binary format, which can be read using the &lt;code>journalctl&lt;/code> command. This command provides a powerful way to filter, search, and manage system logs. By default, systemd stores logs in &lt;code>/var/log/journal&lt;/code>, but this can be configured to use a different location. Don&amp;rsquo;t bother with trying to read the binary logs directly - just use &lt;code>journalctl&lt;/code>.&lt;/p></description></item><item><title>Taming systemd Timer Services to Run Your Daily Backup at a Reasonable Hour</title><link>https://linuxtransfer.com/post/2026-06-09-taming-systemd-timer-services-to-run-your-dai/</link><pubDate>Tue, 09 Jun 2026 09:05:53 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-09-taming-systemd-timer-services-to-run-your-dai/</guid><description>&lt;h2 id="introduction-to-systemd-timer-services">Introduction to systemd Timer Services&lt;/h2>
&lt;p>I&amp;rsquo;ve been using systemd timer services for years to schedule tasks on my Linux systems, and I have to say, they&amp;rsquo;re a game-changer. Most Linux distributions, including Debian, Arch Linux, and OpenSUSE, use systemd as their default init system, so it&amp;rsquo;s worth learning how to use them. In this article, I&amp;rsquo;ll show you how to use systemd timer services to run daily backups at a reasonable hour.&lt;/p></description></item><item><title>Taming systemd-resolved: Troubleshooting DNS leaks and resolving domain name surprises on Linux desktops and servers</title><link>https://linuxtransfer.com/post/2026-06-05-taming-systemd-resolved-troubleshooting-dns-l/</link><pubDate>Fri, 05 Jun 2026 10:35:34 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-05-taming-systemd-resolved-troubleshooting-dns-l/</guid><description>&lt;h2 id="introduction-to-systemd-resolved">Introduction to systemd-resolved&lt;/h2>
&lt;p>I&amp;rsquo;ve seen systemd-resolved become a crucial part of many Linux distributions, including Ubuntu, Debian, and Fedora, as of 2026. It&amp;rsquo;s designed to provide a robust and secure way to resolve domain names on Linux systems. However, like any complex system, it can sometimes behave unexpectedly, leading to DNS leaks and domain name resolution surprises.&lt;/p>
&lt;h2 id="understanding-dns-leaks">Understanding DNS Leaks&lt;/h2>
&lt;p>A DNS leak occurs when your system sends DNS queries to an unintended DNS server, potentially revealing your browsing history and online activities to third parties. This can happen when your system is configured to use a specific DNS server, but systemd-resolved is not properly configured to respect this setting. Don&amp;rsquo;t bother with manually trying to diagnose DNS leaks - just use online tools such as dnsleaktest.com or &lt;a href="https://ipleak.net">ipleak.net&lt;/a> to check for them.&lt;/p></description></item><item><title>Taming systemd-resolved: How to Configure DNS Settings for Split Horizon Environments</title><link>https://linuxtransfer.com/post/2026-06-04-taming-systemd-resolved-how-to-configure-dns-/</link><pubDate>Thu, 04 Jun 2026 11:14:28 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-04-taming-systemd-resolved-how-to-configure-dns-/</guid><description>&lt;h2 id="introduction-to-systemd-resolved">Introduction to systemd-resolved&lt;/h2>
&lt;p>I&amp;rsquo;ve seen many Linux admins struggle with configuring DNS settings for split horizon environments. systemd-resolved, a DNS resolver component of the systemd suite, can make life easier. In this article, I&amp;rsquo;ll walk you through how to configure DNS settings for split horizon environments using systemd-resolved.&lt;/p>
&lt;h2 id="understanding-split-horizon-environments">Understanding Split Horizon Environments&lt;/h2>
&lt;p>Split horizon environments are network setups where multiple DNS servers provide different answers for the same domain name, depending on the client&amp;rsquo;s location or network. I&amp;rsquo;ve encountered this in organizations with multiple offices or data centers, where different DNS servers serve different locations. For example, a company with offices in the US and Europe might have two separate DNS servers, one for each region, providing different IP addresses for the same domain name.&lt;/p></description></item><item><title>Rescuing a Linux System Stuck in Emergency Mode: A Step-by-Step Recovery Guide</title><link>https://linuxtransfer.com/post/2026-06-03-rescuing-a-linux-system-stuck-in-emergency-mo/</link><pubDate>Wed, 03 Jun 2026 11:47:11 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-03-rescuing-a-linux-system-stuck-in-emergency-mo/</guid><description>&lt;h2 id="introduction-to-emergency-mode">Introduction to Emergency Mode&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when a Linux system encounters a critical issue during boot - it may enter Emergency Mode. This mode provides a minimal environment for troubleshooting and recovery. With many Linux distributions, including Debian and Arch Linux, updating their boot processes to use systemd, understanding how to rescue a system stuck in Emergency Mode is crucial.&lt;/p>
&lt;h2 id="identifying-the-issue">Identifying the Issue&lt;/h2>
&lt;p>To rescue a system in Emergency Mode, you first need to identify the cause of the issue. Don&amp;rsquo;t bother with guessing - check the system logs, which are usually available in the &lt;code>/var/log&lt;/code> directory. I usually start with the &lt;code>journalctl&lt;/code> command to view the system logs:&lt;/p></description></item><item><title>Troubleshooting Failed Mounts at Boot Time with systemd and fstab</title><link>https://linuxtransfer.com/post/2026-06-02-troubleshooting-failed-mounts-at-boot-time-wi/</link><pubDate>Tue, 02 Jun 2026 09:15:54 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-02-troubleshooting-failed-mounts-at-boot-time-wi/</guid><description>&lt;h2 id="introduction-to-troubleshooting-failed-mounts">Introduction to Troubleshooting Failed Mounts&lt;/h2>
&lt;p>When I&amp;rsquo;m dealing with a Linux system that won&amp;rsquo;t boot properly, one of the first things I check is the mount points. &lt;code>systemd&lt;/code> and the &lt;code>/etc/fstab&lt;/code> file are crucial in this process, but issues can still arise, leading to failed mounts and potential system instability. In this article, I&amp;rsquo;ll walk you through practical steps to troubleshoot and resolve failed mounts at boot time, focusing on &lt;code>systemd&lt;/code> and &lt;code>fstab&lt;/code> configurations.&lt;/p></description></item><item><title>Taming Disk-Hungry Logs with systemd-journald and logrotate</title><link>https://linuxtransfer.com/post/2026-06-01-taming-disk-hungry-logs-with-systemd-journald/</link><pubDate>Mon, 01 Jun 2026 10:10:58 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-06-01-taming-disk-hungry-logs-with-systemd-journald/</guid><description>&lt;h2 id="introduction-to-log-management">Introduction to Log Management&lt;/h2>
&lt;p>I&amp;rsquo;ve seen log files grow out of control and consume disk space, affecting system performance. To tame disk-hungry logs, I recommend using &lt;code>systemd-journald&lt;/code> and &lt;code>logrotate&lt;/code>. These tools help manage log data, making it easier to troubleshoot, debug, and perform security audits.&lt;/p>
&lt;h2 id="understanding-systemd-journald">Understanding systemd-journald&lt;/h2>
&lt;p>&lt;code>systemd-journald&lt;/code> is a system service that collects and stores log messages from various sources. It provides a centralized logging system, which I find more efficient than traditional text-based log files. To view log messages, use the &lt;code>journalctl&lt;/code> command:&lt;/p></description></item><item><title>Rescuing a Broken Linux System with a systemd Emergency Mode Shell</title><link>https://linuxtransfer.com/post/2026-05-31-rescuing-a-broken-linux-system-with-a-systemd/</link><pubDate>Sun, 31 May 2026 08:26:25 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-31-rescuing-a-broken-linux-system-with-a-systemd/</guid><description>&lt;h2 id="introduction-to-emergency-mode">Introduction to Emergency Mode&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when a Linux system encounters a critical issue during boot - it can be a real headache. But, thankfully, Linux has a built-in safety net called emergency mode. This mode kicks in when there&amp;rsquo;s a failed filesystem check or an inability to mount a necessary partition, providing a minimal environment for troubleshooting and repair. With the advancements in Linux, understanding how to use emergency mode is crucial for system administrators and users alike.&lt;/p></description></item><item><title>Troubleshooting DNS Leaks with systemd-resolved and resolv.conf on a Small Linux Server</title><link>https://linuxtransfer.com/post/2026-05-29-troubleshooting-dns-leaks-with-systemd-resolv/</link><pubDate>Fri, 29 May 2026 08:36:48 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-29-troubleshooting-dns-leaks-with-systemd-resolv/</guid><description>&lt;h2 id="introduction-to-dns-leaks">Introduction to DNS Leaks&lt;/h2>
&lt;p>I&amp;rsquo;ve seen DNS leaks cause issues on even the most secure Linux servers. Ensuring your DNS setup is solid is crucial, and one common problem is a DNS leak, where your system inadvertently reveals your DNS queries to unauthorized parties. In this article, I&amp;rsquo;ll walk you through troubleshooting DNS leaks using &lt;code>systemd-resolved&lt;/code> and &lt;code>resolv.conf&lt;/code> on a Linux server.&lt;/p>
&lt;h2 id="understanding-systemd-resolved">Understanding systemd-resolved&lt;/h2>
&lt;p>&lt;code>systemd-resolved&lt;/code> is a powerful tool that provides DNS resolution capabilities. It&amp;rsquo;s designed to be a caching, validating DNS resolver that can also handle DNSSEC validation. To check if &lt;code>systemd-resolved&lt;/code> is running on your system, use the following command:&lt;/p></description></item><item><title>Debugging systemd Service Startup Failures with systemd-analyze and Journalctl</title><link>https://linuxtransfer.com/post/2026-05-28-debugging-systemd-service-startup-failures-wi/</link><pubDate>Thu, 28 May 2026 11:31:56 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-28-debugging-systemd-service-startup-failures-wi/</guid><description>&lt;h2 id="introduction-to-debugging-systemd-services">Introduction to Debugging systemd Services&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when you&amp;rsquo;re trying to troubleshoot issues with your Linux system - those pesky systemd services can be a real pain. They&amp;rsquo;re the backbone of your system, managing everything from network connections to system logging. Debugging these services can be a daunting task, especially for those new to Linux administration. Fortunately, systemd provides two powerful tools to help you diagnose and resolve issues: &lt;code>systemd-analyze&lt;/code> and &lt;code>journalctl&lt;/code>.&lt;/p></description></item><item><title>Taming Split DNS Chaos with systemd-resolved and Local Hostname Resolution</title><link>https://linuxtransfer.com/post/2026-05-27-taming-split-dns-chaos-with-systemd-resolved-/</link><pubDate>Wed, 27 May 2026 08:34:11 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-27-taming-split-dns-chaos-with-systemd-resolved-/</guid><description>&lt;h2 id="introduction-to-split-dns-chaos">Introduction to Split DNS Chaos&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when working with multiple networks or self-hosted services: split DNS configurations can become a real headache. Luckily, many Linux distributions have started adopting &lt;code>systemd-resolved&lt;/code> as the default DNS resolver, which makes managing split DNS scenarios much simpler. In this article, I&amp;rsquo;ll walk you through how to use &lt;code>systemd-resolved&lt;/code> for local hostname resolution and taming that split DNS chaos.&lt;/p>
&lt;h2 id="understanding-systemd-resolved">Understanding systemd-resolved&lt;/h2>
&lt;p>The real trick is understanding how &lt;code>systemd-resolved&lt;/code> works. It&amp;rsquo;s a systemd component that provides DNS resolution and caching, and it can be configured to use multiple DNS servers and handle split DNS scenarios with ease. To check if &lt;code>systemd-resolved&lt;/code> is enabled on your system, run the following command:&lt;/p></description></item><item><title>Troubleshooting Slow DNS Lookups with systemd-resolved and resolvectl</title><link>https://linuxtransfer.com/post/2026-05-25-troubleshooting-slow-dns-lookups-with-systemd/</link><pubDate>Mon, 25 May 2026 08:57:59 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-25-troubleshooting-slow-dns-lookups-with-systemd/</guid><description>&lt;h2 id="introduction-to-troubleshooting-slow-dns-lookups">Introduction to Troubleshooting Slow DNS Lookups&lt;/h2>
&lt;p>I&amp;rsquo;ve seen slow DNS lookups bring Linux systems to a crawl, and with our increasing reliance on online services, efficient DNS resolution is crucial. This article focuses on troubleshooting slow DNS lookups using &lt;code>systemd-resolved&lt;/code> and &lt;code>resolvectl&lt;/code>, which are integral to many modern Linux distributions.&lt;/p>
&lt;h2 id="understanding-systemd-resolved">Understanding systemd-resolved&lt;/h2>
&lt;p>&lt;code>systemd-resolved&lt;/code> is a system service that provides DNS resolution, replacing traditional implementations like &lt;code>glibc&lt;/code>&amp;rsquo;s resolver. It offers improved security, better DNSSEC handling, and efficient management of multiple DNS servers. To check if it&amp;rsquo;s running on your system, use:&lt;/p></description></item><item><title>Taming systemd-resolved: Avoiding DNS Leaks and Surprises with Split DNS Configurations</title><link>https://linuxtransfer.com/post/2026-05-24-taming-systemd-resolved-avoiding-dns-leaks-an/</link><pubDate>Sun, 24 May 2026 10:21:18 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-24-taming-systemd-resolved-avoiding-dns-leaks-an/</guid><description>&lt;h2 id="introduction-to-systemd-resolved">Introduction to systemd-resolved&lt;/h2>
&lt;p>I&amp;rsquo;ve worked with Linux systems for years, and one thing that&amp;rsquo;s become increasingly important is DNS resolution. systemd-resolved is a DNS resolver component of the systemd suite, designed to provide a flexible and secure way to resolve domain names. It was introduced in systemd version 216, released in 2015, and has since become a standard component in many Linux distributions. By default, systemd-resolved uses a split DNS configuration, which can sometimes lead to DNS leaks and unexpected behavior. I&amp;rsquo;ve seen this go wrong when a system has multiple network interfaces or connections, each with its own DNS resolver configuration.&lt;/p></description></item><item><title>Using systemd to Manage and Rotate Log Files Without Running Out of Disk Space</title><link>https://linuxtransfer.com/post/2026-05-23-using-systemd-to-manage-and-rotate-log-files-/</link><pubDate>Sat, 23 May 2026 11:26:20 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-23-using-systemd-to-manage-and-rotate-log-files-/</guid><description>&lt;h2 id="introduction-to-log-rotation-with-systemd">Introduction to Log Rotation with systemd&lt;/h2>
&lt;p>I&amp;rsquo;ve seen log files consume entire disks, bringing systems to a grinding halt. That&amp;rsquo;s why log rotation is crucial - it ensures your logs don&amp;rsquo;t get out of control. With systemd, you&amp;rsquo;ve got a robust mechanism for managing and rotating logs. In this article, I&amp;rsquo;ll dive into using systemd for log rotation, covering its benefits, configuration, and some practical examples.&lt;/p>
&lt;h2 id="understanding-systemds-role-in-log-rotation">Understanding systemd&amp;rsquo;s Role in Log Rotation&lt;/h2>
&lt;p>systemd&amp;rsquo;s journald is a game-changer for log management. It collects and stores log messages from various sources, including systemd services, kernel messages, and other system components. This centralized logging system makes it easier to manage and rotate logs. By leveraging systemd&amp;rsquo;s capabilities, you can configure log rotation to suit your specific needs, keeping your system stable and secure.&lt;/p></description></item><item><title>Taming systemd-resolved: Tips for Troubleshooting and Customizing DNS Resolution on Linux</title><link>https://linuxtransfer.com/post/2026-05-22-taming-systemd-resolved-tips-for-troubleshoot/</link><pubDate>Fri, 22 May 2026 10:04:50 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-22-taming-systemd-resolved-tips-for-troubleshoot/</guid><description>&lt;h2 id="introduction-to-systemd-resolved">Introduction to systemd-resolved&lt;/h2>
&lt;p>I&amp;rsquo;ve been using systemd-resolved for a while now, and I have to say, it&amp;rsquo;s a big improvement over traditional DNS resolvers. As of 2026, many Linux distributions, including Ubuntu, Debian, and Fedora, have adopted systemd-resolved as the default DNS resolver. While it offers several benefits, including improved security and performance, some users may encounter issues or require customization to suit their specific needs. Don&amp;rsquo;t bother with trying to disable it, though - it&amp;rsquo;s usually worth the effort to get it working right.&lt;/p></description></item><item><title>Using rsync and systemd to Automate Offsite Backups of Selected Config Files and User Data</title><link>https://linuxtransfer.com/post/2026-05-21-using-rsync-and-systemd-to-automate-offsite-b/</link><pubDate>Thu, 21 May 2026 10:49:01 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-21-using-rsync-and-systemd-to-automate-offsite-b/</guid><description>&lt;h2 id="introduction-to-automated-offsite-backups">Introduction to Automated Offsite Backups&lt;/h2>
&lt;p>As a Linux user, you&amp;rsquo;ve probably learned the hard way how important it is to protect your configuration files and user data from loss or corruption. I&amp;rsquo;ve seen this go wrong when a disk fails or a configuration change goes awry. One way to ensure the integrity of this data is to set up automated offsite backups. In this article, we&amp;rsquo;ll explore how to use &lt;code>rsync&lt;/code> and &lt;code>systemd&lt;/code> to create a reliable and efficient backup system.&lt;/p></description></item><item><title>Using jq to Parse and Manipulate JSON Logs from systemd-journald</title><link>https://linuxtransfer.com/post/2026-05-19-using-jq-to-parse-and-manipulate-json-logs-fr/</link><pubDate>Tue, 19 May 2026 08:58:34 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-19-using-jq-to-parse-and-manipulate-json-logs-fr/</guid><description>&lt;h2 id="introduction-to-jq-and-systemd-journald">Introduction to jq and systemd-journald&lt;/h2>
&lt;p>I&amp;rsquo;ve found that working with Linux systems often involves digging through logs to troubleshoot issues. systemd-journald is a key component in this process, collecting and storing log messages from various sources. Since these logs are often in JSON format, tools like &lt;code>jq&lt;/code> become incredibly useful for parsing and manipulation. In this article, I&amp;rsquo;ll walk you through how to use &lt;code>jq&lt;/code> to parse and manipulate JSON logs from systemd-journald.&lt;/p></description></item><item><title>Troubleshooting systemd Service Startup Failures with Dependency Ordering and Journalctl</title><link>https://linuxtransfer.com/post/2026-05-18-troubleshooting-systemd-service-startup-failu/</link><pubDate>Mon, 18 May 2026 10:30:29 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-18-troubleshooting-systemd-service-startup-failu/</guid><description>&lt;h2 id="introduction-to-systemd-service-troubleshooting">Introduction to systemd Service Troubleshooting&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when services fail to start due to complex dependency ordering and logging issues. systemd, with its powerful tools for diagnosing problems, makes it easier to identify and fix these issues. In this article, we&amp;rsquo;ll focus on practical examples of using dependency ordering and &lt;code>journalctl&lt;/code> to troubleshoot systemd service startup failures.&lt;/p>
&lt;h2 id="understanding-systemd-dependencies">Understanding systemd Dependencies&lt;/h2>
&lt;p>systemd services are defined in unit files, typically located in &lt;code>/etc/systemd/system/&lt;/code> or &lt;code>/usr/lib/systemd/system/&lt;/code>. These files specify the service&amp;rsquo;s dependencies, which are crucial for determining the order in which services start. Dependencies are defined using directives like &lt;code>Requires&lt;/code>, &lt;code>Wants&lt;/code>, &lt;code>Before&lt;/code>, and &lt;code>After&lt;/code>. For instance, a web server service might require the network service to be started before it can start itself.&lt;/p></description></item><item><title>Taming Log Rotation in systemd: A Practical Approach to Preventing Disk Bloat</title><link>https://linuxtransfer.com/post/2026-05-17-taming-log-rotation-in-systemd-a-practical-ap/</link><pubDate>Sun, 17 May 2026 10:14:26 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-17-taming-log-rotation-in-systemd-a-practical-ap/</guid><description>&lt;h2 id="introduction-to-log-rotation">Introduction to Log Rotation&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when log files grow out of control, filling up the disk and causing system instability. That&amp;rsquo;s why log rotation is a crucial aspect of Linux system maintenance. With many Linux distributions, including Debian and Arch Linux, adopting systemd as their default init system, understanding how to manage log rotation in a systemd environment is essential. In practice, this means getting familiar with systemd-journald, the component responsible for collecting and storing log messages.&lt;/p></description></item><item><title>Taming systemd Service Restart Behavior with RestartSec and TimeoutStartSec</title><link>https://linuxtransfer.com/post/2026-05-16-taming-systemd-service-restart-behavior-with-/</link><pubDate>Sat, 16 May 2026 08:13:26 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-05-16-taming-systemd-service-restart-behavior-with-/</guid><description>&lt;h2 id="introduction-to-systemd-service-restart-behavior">Introduction to systemd Service Restart Behavior&lt;/h2>
&lt;p>I&amp;rsquo;ve seen this go wrong when a service fails and systemd keeps restarting it, causing more harm than good. To avoid this, it&amp;rsquo;s essential to understand how systemd handles service restarts. Systemd is a core component of most modern Linux distributions, responsible for managing system services, including their startup, runtime, and shutdown. One of the key aspects of systemd service management is its ability to automatically restart services that fail or terminate unexpectedly. However, this behavior can sometimes lead to unintended consequences, such as a service restarting indefinitely in a failed state. To mitigate this, systemd provides two important directives: &lt;code>RestartSec&lt;/code> and &lt;code>TimeoutStartSec&lt;/code>.&lt;/p></description></item></channel></rss>