systemd でのソケットのアクティブ化は、次の 2 つのモードで機能します。
Accept=true:systemd はリスニング ソケットを保持し、すべての着信接続を受け入れ、接続ごとに新しいプロセスを生成し、確立されたソケットをそれに渡します。このケースは些細なことです (各プロセスは完了すると終了します)。Accept=false:systemd はリスニング ソケットを作成し、着信接続を監視します。入ってくるとすぐに、systemd はサービスを生成し、リスニング ソケットをそれに渡します。その後、サービスは着信接続と後続の接続を受け入れます。 Systemd はソケットで何が起こっているかを追跡しないため、非アクティブを検出できません。
後者の場合、真にクリーンな唯一の解決策は、アプリケーションがしばらくアイドル状態になったときに終了するようにアプリケーションを変更することだと思います。それができない場合、大雑把な回避策として、cron または systemd タイマーを設定して、1 時間に 1 回サービスを強制終了することができます。サービスが非常にまれにしか生成されない場合、これは妥当な概算となる可能性があります。
ユースケースはおそらくかなりまれであることに注意してください。接続を待機している poll()/select() 内のプロセスは CPU 時間を消費しないため、その状況で使用される唯一のリソースはメモリです。スワップをセットアップして、プロセスを常に RAM に保持する価値があるかどうかをカーネルに判断させる方が、おそらく簡単かつ効率的です。