Summary
rofi -dmenu intermittently exits with code 1 (cancel, nothing selected) within 0.4-1.8s of launch, without any user input. Same binary, same input, same display: some runs survive indefinitely, some die sub-second. The failure correlates with stdin EOF timing.
Repro
printf 'Alpha\nBeta\nGamma\n' | timeout 6 rofi -dmenu -p probe -l 3
Observed over 5 consecutive runs (rofi 2.0.0, X11/i3, xcb backend):
run 1: rc=124 (survived, killed by timeout)
run 2: rc=124 (survived)
run 3: rc=124 (survived)
run 4: rc=1 elapsed_ms=915
run 5: rc=1 elapsed_ms=373
Earlier the same command with -config /dev/null died 2/2 (1.36s, 1.55s), then later survived 5/5 — load/timing dependent. The real config (which disables inputbar/prompt) dies more often, but the empty config reproduces it too, so the config timeout { action: "kb-cancel"; delay: 0; } block is not the trigger.
EOF correlation (deterministic when EOF arrives late)
Keeping stdin open delays the death until the pipe closes:
(printf 'Alpha\nBeta\n'; sleep 8) | timeout 10 rofi -dmenu -p probe -l 3 -config /dev/null
# rc=1 at 8.001s — exits the instant EOF arrives, long after startup
With a FIFO whose writer exits immediately, rofi survives indefinitely (10s+, killed by timeout). So: EOF after startup exits deterministically; EOF during startup exits nondeterministically (race between the async stdin reader finishing and view startup).
What I ruled out
- Config timeout block (reproduced with
-config /dev/null).
- dmenu read thread signaling:
read_input_thread on EOF writes "q" to the IPC pipe and exits; dmenu_async_read_proc treats 'q' as overlay-clear only, never cancels. That path is identical between 2.0.0 and current master (a6baa2a).
- pidfile (
create_pid_file uses flock; lock is released on process exit, no stale-lock interference in the repro).
Suspects
Cancel (MENU_CANCEL, rc=1) is otherwise only reachable via keybindings or the timeout action. Since no input occurs, I suspect an X11-backend startup event (window mapping/focus race with the WM, or the stdin EOF racing the view's first update) being interpreted as cancel. A debug build with symbols would pin it down quickly. Happy to run more probes or capture additional traces if helpful.
Impact
Breaks any something | rofi -dmenu launcher: menus randomly vanish ~1s after appearing. Present in 2.0.0; not obviously fixed in the 74 commits since the tag (no commit touches this path).
Summary
rofi -dmenuintermittently exits with code 1 (cancel, nothing selected) within 0.4-1.8s of launch, without any user input. Same binary, same input, same display: some runs survive indefinitely, some die sub-second. The failure correlates with stdin EOF timing.Repro
Observed over 5 consecutive runs (rofi 2.0.0, X11/i3, xcb backend):
Earlier the same command with
-config /dev/nulldied 2/2 (1.36s, 1.55s), then later survived 5/5 — load/timing dependent. The real config (which disablesinputbar/prompt) dies more often, but the empty config reproduces it too, so the configtimeout { action: "kb-cancel"; delay: 0; }block is not the trigger.EOF correlation (deterministic when EOF arrives late)
Keeping stdin open delays the death until the pipe closes:
With a FIFO whose writer exits immediately, rofi survives indefinitely (10s+, killed by timeout). So: EOF after startup exits deterministically; EOF during startup exits nondeterministically (race between the async stdin reader finishing and view startup).
What I ruled out
-config /dev/null).read_input_threadon EOF writes"q"to the IPC pipe and exits;dmenu_async_read_proctreats'q'as overlay-clear only, never cancels. That path is identical between 2.0.0 and current master (a6baa2a).create_pid_fileuses flock; lock is released on process exit, no stale-lock interference in the repro).Suspects
Cancel (
MENU_CANCEL, rc=1) is otherwise only reachable via keybindings or the timeout action. Since no input occurs, I suspect an X11-backend startup event (window mapping/focus race with the WM, or the stdin EOF racing the view's first update) being interpreted as cancel. A debug build with symbols would pin it down quickly. Happy to run more probes or capture additional traces if helpful.Impact
Breaks any
something | rofi -dmenulauncher: menus randomly vanish ~1s after appearing. Present in 2.0.0; not obviously fixed in the 74 commits since the tag (no commit touches this path).