<?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 Margrop Blog</title>
    <link>https://blog.margrop.net/en/tag/systemd/</link>
    <description>Recent content in Systemd on Margrop Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-US</language>
    <lastBuildDate>Fri, 19 Jun 2026 10:58:00 +0800</lastBuildDate>
    <atom:link href="https://blog.margrop.net/en/tag/systemd/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>One sentence let Claude upgrade Ubuntu 22.04 to 24.04: a near-zero-screen-time cross-LTS run</title>
      <link>https://blog.margrop.net/en/post/upgrade-ubuntu-via-agent/</link>
      <pubDate>Fri, 19 Jun 2026 10:58:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/upgrade-ubuntu-via-agent/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;A remote home-lab box had been sitting on Ubuntu 22.04.4 LTS (jammy, kernel 5.15) for a long time. After one sentence — &amp;ldquo;upgrade the box at 192.168.103.182 to Ubuntu 24.04&amp;rdquo; — Claude opened a tmux session to babysit the run, brought up a fallback sshd on port 1022 so a mid-upgrade sshd restart would not strand me, then drove &lt;code&gt;do-release-upgrade -f DistUpgradeViewNonInteractive&lt;/code&gt; end to end. Twenty-five minutes later the host came back: kernel 6.8.0-124, every service still listening.&lt;/p&gt;&#xA;&lt;p&gt;This is not a tutorial on &lt;code&gt;do-release-upgrade&lt;/code&gt;; the Ubuntu docs already cover that. This is about what an Agent does once it gets an SSH handle on a box, why it does each step, and which pitfalls you have to clear out of the way before letting it loose.&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>Ubuntu shutdown stuck for 90 seconds? A Python asyncio service that won&#39;t honour SIGTERM, and how to fix it</title>
      <link>https://blog.margrop.net/en/post/ubuntu-shutdown-stuck/</link>
      <pubDate>Fri, 19 Jun 2026 10:58:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/ubuntu-shutdown-stuck/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;After upgrading my home proxy box to Ubuntu 24.04, &lt;code&gt;systemctl reboot&lt;/code&gt; stopped being fast: SSH would hang on for &lt;strong&gt;90 seconds&lt;/strong&gt; before the box actually shut down. &lt;code&gt;journalctl&lt;/code&gt; made it obvious: &lt;code&gt;smart-proxy.service: State &#39;stop-sigterm&#39; timed out. Killing.&lt;/code&gt; — systemd sent SIGTERM, waited 90 seconds, nobody reacted, and SIGKILL was the only option left.&lt;/p&gt;&#xA;&lt;p&gt;The root cause is not systemd&amp;rsquo;s fault and not Ubuntu&amp;rsquo;s fault. It is &lt;strong&gt;Python&amp;rsquo;s asyncio runtime not actually ending its child tasks when SIGTERM arrives&lt;/strong&gt; — it is parked on a &lt;code&gt;socket.recv&lt;/code&gt; and never voluntarily looks at the signal queue.&lt;/p&gt;&#xA;&lt;p&gt;The fix has two halves, both required: &lt;strong&gt;(1)&lt;/strong&gt; a systemd drop-in that lowers &lt;code&gt;TimeoutStopSec&lt;/code&gt; from the default 90s down to 20s on the affected Python units; &lt;strong&gt;(2)&lt;/strong&gt; inside the Python service itself, walk &lt;code&gt;asyncio.all_tasks()&lt;/code&gt;, &lt;code&gt;.cancel()&lt;/code&gt; the in-flight connection handlers on SIGTERM, and wrap &lt;code&gt;self.stop()&lt;/code&gt; in &lt;code&gt;asyncio.wait_for(..., timeout=10)&lt;/code&gt; as a safety net. After both halves, the same &lt;code&gt;reboot&lt;/code&gt; drops from 90 seconds to one second.&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>Avoiding the Trap: Why Fail2Ban Fails on Ubuntu 26.04 &amp; PVE 9.2 (And How to Fix It)</title>
      <link>https://blog.margrop.net/en/post/ubuntu-2604-pve-92-fail2ban-nftables-guide/</link>
      <pubDate>Tue, 26 May 2026 22:20:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/ubuntu-2604-pve-92-fail2ban-nftables-guide/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;The Bottom Line&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;With the releases of Ubuntu 26.04 LTS and Proxmox VE (PVE) 9.2, many system administrators, DevOps engineers, and self-hosting enthusiasts have eagerly upgraded or clean-installed these latest systems. However, during the post-installation security hardening phase, you may encounter a highly frustrating scenario: &lt;strong&gt;simply copying over your legacy Fail2Ban configuration files from older versions (such as Ubuntu 20.04/22.04 or PVE 7.x/8.x) will either cause the Fail2Ban service to crash during startup or, worse, run silently in the background while completely failing to block external brute-force attacks!&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;This issue is not caused by a bug in Fail2Ban itself. Instead, it is the result of three &amp;ldquo;invisible bombs&amp;rdquo; hidden beneath the surface of these modern Linux distributions, namely changes in the logging architecture, service activation mechanisms, and firewall backends. This article provides an in-depth analysis of these three architectural shifts and introduces a modern, bulletproof Fail2Ban configuration guide fully integrated with &lt;code&gt;systemd-journald&lt;/code&gt; and &lt;code&gt;nftables&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>Forget Bloated VPNs! Step-by-Step EasyTier Setup on Ubuntu 26.04 for a Decentralized Virtual LAN</title>
      <link>https://blog.margrop.net/en/post/ubuntu-2604-install-latest-easytier-guide/</link>
      <pubDate>Tue, 26 May 2026 21:40:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/ubuntu-2604-install-latest-easytier-guide/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;In today&amp;rsquo;s multi-device environment, virtual private networking has become an absolute necessity. While classic tools like ZeroTier and Tailscale are excellent, they are fundamentally constrained by centralized controllers and overseas relay servers, leading to slow handshakes and lower NAT hole-punching success rates. On the other hand, self-hosting frp or nps requires a public IP address, and all traffic must pass through the proxy server, severely limiting bandwidth.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;EasyTier&lt;/strong&gt; is a completely decentralized virtual LAN tool written in Rust. Its defining feature is &lt;strong&gt;peer symmetry (peer-to-peer equivalence)&lt;/strong&gt;. Once nodes are introduced, they maintain stable P2P communication even if the initial bootstrap/relay server goes offline. Even more exciting, it natively supports &lt;strong&gt;subnet proxying (network-to-network)&lt;/strong&gt; and a &lt;strong&gt;built-in WireGuard portal&lt;/strong&gt;. This step-by-step guide will walk you through installing, configuring, and managing the latest EasyTier via Systemd on the newly released &lt;strong&gt;Ubuntu 26.04 LTS&lt;/strong&gt;.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;All configurations, commands, and network topologies in this article use generic placeholders and do not contain any real private or sensitive information.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
