<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>systemd on Ikoma's Blog</title><link>https://blog.yusukeikoma.com/tags/systemd/</link><description>Recent content in systemd on Ikoma's Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 03 Oct 2026 18:08:27 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/tags/systemd/index.xml" rel="self" type="application/rss+xml"/><item><title>Socket Activation Keeps Connections Waiting, Not Refused, During a systemd Restart</title><link>https://blog.yusukeikoma.com/posts/replace-running-daemon-without-downtime/</link><pubDate>Sat, 03 Oct 2026 18:08:27 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/replace-running-daemon-without-downtime/</guid><description>A runbook for replacing a running daemon without dropping requests, tested on a small TCP server under real systemd. A plain restart refused or reset connections every time; starting the new version beside the old one avoided refusals but still reset a connection in some runs, and a kernel setting made those resets go away; socket activation produced no errors. Also covered: draining in-flight work against TimeoutStopSec, and a release swap that checks the new version and rolls back.</description></item><item><title>systemd Kills the Updater Your Service Started, Even With setsid</title><link>https://blog.yusukeikoma.com/posts/systemd-killmode-self-update/</link><pubDate>Mon, 28 Sep 2026 09:48:47 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/systemd-killmode-self-update/</guid><description>A daemon that updates itself by starting a helper and restarting its own unit has a trap: the helper starts inside the service&amp;rsquo;s cgroup, and systemd kills everything in that cgroup on restart. In a throwaway systemd, a setsid&amp;rsquo;d helper vanished before its last log line, KillMode=process kept it alive but leaked it into the next instance, and systemd-run gave it its own unit. This post shows the evidence, the fix, and what I did not test.</description></item></channel></rss>