<?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>linux on Ikoma's Blog</title><link>https://blog.yusukeikoma.com/tags/linux/</link><description>Recent content in linux 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/linux/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><item><title>Two write() Calls Can Stall a TCP Connection for 40 ms</title><link>https://blog.yusukeikoma.com/posts/two-small-writes-nagle-delayed-ack/</link><pubDate>Tue, 01 Sep 2026 20:56:28 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/two-small-writes-nagle-delayed-ack/</guid><description>Send a header and a body as two small write() calls, then wait for a reply, and every round trip can stall for about 40 ms on an idle machine with an idle network. Neither Nagle&amp;rsquo;s algorithm nor delayed ACK is a bug; together they deadlock until a timer fires. This post predicts the stall, reproduces it with a 50-line script, reads it off a packet trace, and compares the four ways out.</description></item><item><title>Edge-Triggered epoll Hangs After a Partial Read, and Event Streams Break the Same Way</title><link>https://blog.yusukeikoma.com/posts/level-triggered-invalidation/</link><pubDate>Tue, 25 Aug 2026 17:33:01 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/level-triggered-invalidation/</guid><description>epoll&amp;rsquo;s edge-triggered mode stalls after a partial read; level-triggered mode cannot. The same distinction decides whether a realtime client survives lost, duplicated and reordered events. A reproducible epoll experiment, a five-way simulation on a lossy channel, and a 40-line invalidator that handles the race everyone misses: an event that arrives while the refetch is running.</description></item><item><title>A Dead TCP Peer Goes Unnoticed for 15 Minutes on Writes, Forever on Reads</title><link>https://blog.yusukeikoma.com/posts/tcp-half-open-connection-detection/</link><pubDate>Sun, 23 Aug 2026 15:09:06 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/tcp-half-open-connection-detection/</guid><description>TCP never tells you that the peer is gone. A reader blocks forever, a writer keeps retransmitting for a quarter of an hour, and SO_KEEPALIVE does nothing while data is unacknowledged. This post builds a one-file Linux lab with no root, climbs a ladder of mechanisms (nothing, keepalive, TCP_USER_TIMEOUT, an application heartbeat), measures how long each takes to notice, and shows where NAT and the RFCs fit in.</description></item></channel></rss>