<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Open-Source on Linux Security</title><link>https://linuxtransfer.com/tags/open-source/</link><description>Recent content in Open-Source on Linux Security</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 06 Sep 2026 08:50:12 +0200</lastBuildDate><atom:link href="https://linuxtransfer.com/tags/open-source/index.xml" rel="self" type="application/rss+xml"/><item><title>Why Your systemd Service Stays “activating” After a Kernel Upgrade – A Step‑by‑Step Fix​</title><link>https://linuxtransfer.com/post/2026-09-06-why-your-systemd-service-stays-activating-aft/</link><pubDate>Sun, 06 Sep 2026 08:50:12 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-09-06-why-your-systemd-service-stays-activating-aft/</guid><description>&lt;h2 id="why-a-service-can-stay-activating-after-a-kernel-upgrade">Why a service can stay “activating” after a kernel upgrade&lt;/h2>
&lt;p>When you bump the kernel, systemd does a hard reset of almost everything.&lt;br>
If a unit you depend on never leaves the &lt;em>activating&lt;/em> state, the rest of the boot can stall or the service simply never runs.&lt;br>
The usual suspect is a dependency on a kernel‑provided resource that is missing or delayed after the upgrade.&lt;/p>
&lt;p>Below is a practical checklist that shows how to diagnose the issue, why it happens, and how to fix it without compromising security or stability.&lt;/p></description></item><item><title>Taming the DNS Resolver: Mastering resolvectl for Faster and More Reliable Internet Connections</title><link>https://linuxtransfer.com/post/2026-09-05-taming-the-dns-resolver-mastering-resolvectl-/</link><pubDate>Sat, 05 Sep 2026 11:24:54 +0200</pubDate><guid>https://linuxtransfer.com/post/2026-09-05-taming-the-dns-resolver-mastering-resolvectl-/</guid><description>&lt;h2 id="why-systemdresolved-matters">Why systemd‑resolved matters&lt;/h2>
&lt;p>On most modern distros the DNS stack is no longer a simple &lt;code>/etc/resolv.conf&lt;/code>.&lt;br>
&lt;code>systemd‑resolved&lt;/code> runs in the background, pulls DNS servers from every
interface, does caching, validates with DNSSEC, and even acts as a local
DNS‑over‑TLS (DoT) proxy.&lt;br>
&lt;code>resolvectl&lt;/code> (now &lt;code>systemd-resolve&lt;/code> in newer releases) is the CLI that lets you
look inside this stack and tweak it without hunting through config files.&lt;/p>
&lt;p>If you run a home lab, self‑hosted services, or just want a snappier, more
reliable lookup, mastering &lt;code>resolvectl&lt;/code> can shave milliseconds off each
query and give you a clear view of what the resolver is actually doing.&lt;/p></description></item></channel></rss>