<?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/ja/tags/linux/</link><description>Recent content in linux on Ikoma's Blog</description><generator>Hugo</generator><language>ja-jp</language><lastBuildDate>Sat, 03 Oct 2026 18:08:27 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/ja/tags/linux/index.xml" rel="self" type="application/rss+xml"/><item><title>systemdの再起動中、ソケットアクティベーションなら接続は拒否されず、待たされる</title><link>https://blog.yusukeikoma.com/ja/posts/replace-running-daemon-without-downtime/</link><pubDate>Sat, 03 Oct 2026 18:08:27 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/replace-running-daemon-without-downtime/</guid><description>稼働中のデーモンをリクエストを落とさずに入れ替える手順書です。小さなTCPサーバーを本物のsystemdで動かして試しました。単純なrestartは毎回、接続の拒否かリセットを起こしました。SO_REUSEPORTで新旧を並べる方法は拒否ゼロでしたが、一部の回でリセットが出て、カーネルの設定でそれが消えました。ソケットアクティベーションはエラーなしでした。処理中リクエストのドレインとTimeoutStopSecの関係、新バージョンを確認して巻き戻すリリース切り替えも扱います。</description></item><item><title>サービスが起動した更新プロセスは、setsidしてもsystemdに殺される</title><link>https://blog.yusukeikoma.com/ja/posts/systemd-killmode-self-update/</link><pubDate>Mon, 28 Sep 2026 09:48:47 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/systemd-killmode-self-update/</guid><description>自分自身を更新するデーモンが、更新用のヘルパーを起動してから自分のユニットを再起動すると、落とし穴があります。ヘルパーはサービスのcgroupの中で起動し、再起動時にsystemdがそのcgroupの中身を全部終了させるからです。使い捨てのsystemdで試すと、setsidしたヘルパーは最後のログ行を出す前に消え、KillMode=processでは生き残るものの次のインスタンスに紛れ込み、systemd-runなら独立したユニットとして最後まで動きました。証拠、直し方、試していないことを書きます。</description></item><item><title>write() を2回呼ぶだけで、TCPが40ms止まる</title><link>https://blog.yusukeikoma.com/ja/posts/two-small-writes-nagle-delayed-ack/</link><pubDate>Tue, 01 Sep 2026 20:56:28 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/two-small-writes-nagle-delayed-ack/</guid><description>ヘッダーと本文を小さな write() 2回に分けて送り、返事を待つと、CPUもネットワークも空いているのに、1往復ごとに約40ms止まることがあります。Nagleアルゴリズムも遅延ACKも、単体では正しい仕様です。2つが組み合わさると、タイマーが切れるまで互いに待ち合ってしまいます。この記事では、停止を予想し、50行のスクリプトで再現し、パケットトレースで確かめ、4つの対処を比べます。</description></item><item><title>エッジトリガーのepollは部分読みで止まる。イベント配信も、同じ理由で壊れる</title><link>https://blog.yusukeikoma.com/ja/posts/level-triggered-invalidation/</link><pubDate>Tue, 25 Aug 2026 17:33:01 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/level-triggered-invalidation/</guid><description>epoll のエッジトリガーは部分的に読むと止まりますが、レベルトリガーは止まりません。同じ違いが、イベントの喪失・重複・順序入れ替えに耐えられるかを分けます。再現できる epoll の実験、損失のあるチャネル上での5通りのシミュレーション、そして見落とされがちな競合(再取得の最中に届いたイベント)を扱う40行ほどの invalidator を紹介します。</description></item><item><title>死んだTCPの相手に気づくまで、書く側は約15分、読むだけの側は無期限</title><link>https://blog.yusukeikoma.com/ja/posts/tcp-half-open-connection-detection/</link><pubDate>Sun, 23 Aug 2026 15:09:06 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/tcp-half-open-connection-detection/</guid><description>TCP は、相手がいなくなったことを教えてくれません。読み取り側は永遠にブロックし、書き込み側は十数分も再送を続け、SO_KEEPALIVE は未確認のデータがあるあいだ何もしません。この記事では、root 不要の1ファイルの Linux 実験環境を作り、何もしない、keepalive、TCP_USER_TIMEOUT、アプリケーションのハートビートという順に仕組みを積み上げて、気づくまでの時間を測ります。NAT と RFC がどこに関わるかも整理します。</description></item></channel></rss>