Server drops all clients and remains alive without status API socket on WSL2

[Dvitash]

Is this a reproducible bug?

• I confirm this is a reproducible bug, not a feature request, idea, question, contribution proposal, or direction check.
• I reproduced this bug on the version and environment reported below using the exact steps provided.

Current behavior

During normal use with several OMP panes, Herdr intermittently drops every client with herdr: lost connection to server: server closed connection and sends SIGHUP to all pane processes. This occurred several times in one day; one occurrence followed a large paste, but later occurrences happened without a large paste or other known trigger.

After the latest occurrence, the server process was still alive, but ~/.config/herdr/herdr.sock was absent. Recovery commands then disagreed about server state:

$ herdr server stop
server is not running or cannot be reached at /home/dvita/.config/herdr/herdr.sock: No such file or directory (os error 2)

$ herdr
herdr: a herdr server is listening, but its status API is unavailable.

ps -C herdr showed the surviving process as /home/dvita/.local/bin/herdr server. A manual SIGTERM removed it. Server logs contain only the pane Hangup cascade; client logs record app.shutdown. There is no panic or originating error in either log. This resembles #1228, but adds a concrete partial-shutdown state where the server survives without its status API socket.

Expected behavior

The server and panes should remain available during normal use. If the server encounters an error, it should preserve or cleanly terminate its sockets and process so herdr server stop and a subsequent herdr invocation can recover without a manual kill.

Reproduction

1. On WSL2, run Herdr 0.7.5 on the stable channel.
2. Create multiple panes/workspaces and run OMP sessions in several panes.
3. Continue normal interactive use.
4. Intermittently, all clients disconnect and all pane processes receive SIGHUP.
5. Before restarting, run ps -C herdr -o pid,ppid,sid,stat,cmd and check ~/.config/herdr/herdr.sock.
6. Observe that the herdr server process can remain alive while the status API socket is missing; herdr server stop returns ENOENT, while herdr reports that a server is listening but its status API is unavailable.

The failure reproduced several times in one day, but the action that initiates the shutdown has not been isolated.

Impact

All active agent panes are terminated simultaneously, in-progress session output can be lost, and Herdr cannot restart until the surviving server process is killed manually.

Environment

• Herdr version: 0.7.5 (protocol 17)
• Update channel (stable or preview): stable
• Operating system: Ubuntu 26.04 LTS on WSL2, kernel 6.6.114.1-microsoft-standard-WSL2
• Terminal: Windows Terminal
• Shell, if relevant: bash
• Relevant config, if any: no custom quit/stop/shutdown keybindings

[ogulcancelik]

Thanks. I can’t reproduce this outside WSL2. Could you run this once while Herdr is healthy, then again immediately after the next failure before killing or restarting the server, and attach both files?

out="$HOME/herdr-2006-$(date +%Y%m%d-%H%M%S).txt"
{
  date -Ins
  herdr --version
  herdr status server
  ps -C herdr -o pid,ppid,sid,lstart,stat,args
  ls -li ~/.config/herdr/herdr*.sock
  ss -xlpn | grep herdr || true

  for pid in $(pgrep -f '[h]erdr server'); do
    echo "=== server PID $pid ==="
    cat "/proc/$pid/stat"
    readlink "/proc/$pid/exe"
    echo "open fds: $(ls "/proc/$pid/fd" | wc -l)"
    ls -l "/proc/$pid/fd" | grep 'socket:' || true
  done

  tail -n 200 ~/.config/herdr/herdr-server.log
  tail -n 200 ~/.config/herdr/herdr-client.log
} >"$out" 2>&1
echo "$out"

Please also note the approximate failure time. Feel free to redact private paths or command arguments.