Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Shutdown delay due to hanging sessions (Walker)
Reported by sspaeti · filed Aug 18, 2025Closed upstream on 2025-08-22 by dhh. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Issue Description
I have A stop job running for Session 1..User sspaeti (....` on almost all occasions when I shut down. When I analyze what causes it, it points to Walker being the cultprint - Here's the analysis:
Walker launched with --gapplication-service flag causes system shutdown to hang for 2 minutes before timing out. The issue occurs specifically with walker spawning multiple child processes that don't terminate gracefully.
System Information
- Walker: Started via Omarchy autostart configuration:
uwsm app -- walker --gapplication-service(line 7 in/home/sspaeti/.local/share/omarchy/default/hypr/autostart.conf)
Detailed Logs
From journalctl --boot=-1:
Shutdown sequence showing the hang:
Aug 18 19:21:11 ssp-arch systemd[1132]: Stopping walker...
Aug 18 19:21:11 ssp-arch systemd[1132]: Stopped walker.
Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Stopping timed out. Killing.
Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Failed with result 'timeout'.Process explosion:
Walker spawned 38 processes total (3 named "walker", 35 unnamed child processes) that required SIGKILL:
Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Killing process 52004 (walker) with signal SIGKILL.
Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Killing process 52037 (walker) with signal SIGKILL.
Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Killing process 52038 (n/a) with signal SIGKILL.
[... 35 more unnamed processes killed with SIGKILL ...]
Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Killing process 557933 (n/a) with signal SIGKILL.Resource consumption:
Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Consumed 2min 29.732s CPU time, 3.8G memory peak, 1.1G memory swap peak.Expected Behavior
Walker should terminate gracefully during system shutdown without requiring SIGKILL.
Current Behavior
- System hangs often and showing "A stop job is running for session X_user sspaeti (around 2 mins)"
- Walker scope spawns 38 total processes (3 walker processes + 35 unnamed children)
- All processes ignore SIGTERM, require SIGKILL after timeout
- High resource consumption (3.8GB RAM, 1.1GB swap)
- Note: After fresh restart, walker runs normally as a single process until next shutdown
Solutions?
Any ideas what to do? Are others also having this behaviour? Am I doing something wrong?
Can we implement signal handling for Walker to gracefully terminate child processes? Sorry, I'm a novice to Walker and Linux, not sure how to do this. Claude, help me analyze the logs and the root causes.
View raw text
## Issue Description I have A stop job running for Session 1..User sspaeti (....` on almost all occasions when I shut down. When I analyze what causes it, it points to Walker being the cultprint - Here's the analysis: Walker launched with `--gapplication-service` flag causes system shutdown to hang for 2 minutes before timing out. The issue occurs specifically with walker spawning multiple child processes that don't terminate gracefully. ## System Information - Walker: Started via Omarchy autostart configuration: `uwsm app -- walker --gapplication-service` (line 7 in `/home/sspaeti/.local/share/omarchy/default/hypr/autostart.conf`) ## Detailed Logs From `journalctl --boot=-1`: ### Shutdown sequence showing the hang: ``` Aug 18 19:21:11 ssp-arch systemd[1132]: Stopping walker... Aug 18 19:21:11 ssp-arch systemd[1132]: Stopped walker. Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Stopping timed out. Killing. Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Failed with result 'timeout'. ``` ### Process explosion: Walker spawned 38 processes total (3 named "walker", 35 unnamed child processes) that required SIGKILL: ``` Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Killing process 52004 (walker) with signal SIGKILL. Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Killing process 52037 (walker) with signal SIGKILL. Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Killing process 52038 (n/a) with signal SIGKILL. [... 35 more unnamed processes killed with SIGKILL ...] Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Killing process 557933 (n/a) with signal SIGKILL. ``` ### Resource consumption: ``` Aug 18 19:22:41 ssp-arch systemd[1132]: app-Hyprland-walker-d80612f5.scope: Consumed 2min 29.732s CPU time, 3.8G memory peak, 1.1G memory swap peak. ``` ## Expected Behavior Walker should terminate gracefully during system shutdown without requiring SIGKILL. ## Current Behavior - System hangs often and showing "A stop job is running for session X_user sspaeti (around 2 mins)" - Walker scope spawns 38 total processes (3 walker processes + 35 unnamed children) - All processes ignore SIGTERM, require SIGKILL after timeout - High resource consumption (3.8GB RAM, 1.1GB swap) - **Note**: After fresh restart, walker runs normally as a single process until next shutdown ## Solutions? Any ideas what to do? Are others also having this behaviour? Am I doing something wrong? Can we implement signal handling for Walker to gracefully terminate child processes? Sorry, I'm a novice to Walker and Linux, not sure how to do this. Claude, help me analyze the logs and the root causes.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.