dotfiles/dot_local/bin/executable_zellij-inhibit-watcher, branch master

refactor(suspend): gate suspend on AC, drop bespoke zellij inhibit

2026-05-29T10:18:15Z

New, simpler suspend policy: AC plugged in -> never auto-suspends (lid close ignored, idle no-op) On battery only -> lid close suspends, swayidle suspends at 30 min idle This replaces the SSH/zellij-aware inhibit machinery with a rule that matches the user's mental model: if you don't want the machine to sleep, plug it in. Long-running tasks (builds, downloads, SSH sessions, headless services) just need AC. Changes: * etc/systemd/logind.conf.d/20-lid-ac.conf: set HandleLidSwitchExternalPower=ignore so logind itself handles the AC case at the source. No userspace daemon, no race, no rate-limit risk. * dot_local/bin/on-battery-suspend: tiny POSIX wrapper that exits 0 when any /sys/class/power_supply/{AC,ADP}*/online == 1, else execs `systemctl suspend`. * dot_config/systemd/user/swayidle.service: add `timeout 1800 on-battery-suspend`. Idle suspend now exists, but only when on battery. * Delete zellij-inhibit-suspend.{path,service} + watcher script and remove the entry from systemd-units/user.txt. The .path re-trigger storm bug is moot because the whole mechanism is gone. Manual suspends (sway XF86Sleep keybind, sway power submode `s`, `systemctl suspend` over SSH) still always work regardless of AC -- explicit user intent wins. Also drop /migrate-podman-to-btrfs.sh from .gitignore; the one-off migration script has been deleted now that the user has switched their podman storage to the btrfs driver. On-host steps to apply: chezmoi apply -v systemctl --user daemon-reload systemctl --user reset-failed zellij-inhibit-suspend.service zellij-inhibit-suspend.path || true systemctl --user stop zellij-inhibit-suspend.path zellij-inhibit-suspend.service || true systemctl --user disable zellij-inhibit-suspend.path || true systemctl --user restart swayidle.service # logind drop-in is reloaded automatically by the etc deploy script. Verify: systemctl status systemd-logind | grep -i lid loginctl show-session $XDG_SESSION_ID | grep -i lid # Unplug AC -> close lid -> should suspend. # Plug AC -> close lid -> nothing happens.

fix(suspend): make zellij inhibit watcher resilient to local-only sessions

2026-05-29T10:18:15Z

The previous watcher exited immediately whenever no SSH-spawned zellij was present. That caused a start-rate-limit storm: .path triggers service (zellij dir non-empty) -> watcher exits because no SSH zellij -> service stops -> .path retriggers (zellij dir still non-empty) -> ... 5 starts in 10s, systemd stops the path unit -> no inhibitor ever again, even after you SSH in Restructure so the watcher stays alive for the entire zellij socket directory lifetime and acquires/releases its own systemd-inhibit lock dynamically based on SSH-zellij presence: * Watcher now polls and exits only when the zellij socket dir is empty, matching the .path's trigger condition so it never re-fires while zellij is alive. * systemd-inhibit removed from ExecStart - watcher self-inhibits via a child 'systemd-inhibit ... sleep infinity' it can terminate on demand. * StartLimitIntervalSec=0 on the service as belt-and-braces against any future regression of the cycle. Recovery from the rate-limit hit: systemctl --user reset-failed zellij-inhibit-suspend.service zellij-inhibit-suspend.path systemctl --user daemon-reload systemctl --user restart zellij-inhibit-suspend.path

fix(suspend): only inhibit for SSH-spawned zellij sessions

2026-05-29T10:18:14Z

A local zellij session (sway terminal, attended) shouldn't keep the laptop awake — that's the user actively in front of the machine, and normal suspend behaviour should apply. Only zellij sessions that were spawned from an SSH context need the persistent inhibit, so detach + disconnect leaves the host awake until the session ends. Use /proc//environ to detect SSH-spawned zellij: the daemonised zellij server is exec'd by the client and Linux preserves the exec-time environment for the life of the process, so SSH_CONNECTION= survives the SSH session closing. Walk every running `zellij` pid; hold the lock as long as at least one of them has SSH_CONNECTION in its environ. The .path unit still fires on every zellij socket creation, but if no SSH-spawned zellij exists the watcher exits immediately and the service stops with no harm done — a couple of cheap process spawns per local session start, no inhibitor side-effects.

feat(suspend): hold inhibit lock while any zellij session exists

2026-05-29T10:18:13Z

The SSH-shell inhibitor in dot_zprofile is bound to the lifetime of the login shell, so it disappears the moment the user detaches a zellij session and disconnects — defeating the whole point of using zellij for persistent remote work. Add a user-scope path+service+watcher trio that ties the inhibit lock to the existence of zellij sessions instead: - dot_local/bin/executable_zellij-inhibit-watcher Polls `zellij list-sessions --short` every 15s, exits when none remain. Override poll interval via $ZELLIJ_INHIBIT_POLL. - dot_config/systemd/user/zellij-inhibit-suspend.service Wraps the watcher in `systemd-inhibit --what=sleep:idle:handle-lid-switch --mode=block`. When the watcher exits, the service stops and the lock is released. - dot_config/systemd/user/zellij-inhibit-suspend.path Activates the service whenever $XDG_RUNTIME_DIR/zellij becomes non-empty (i.e. zellij creates its first session socket). Re-fires on every empty→non-empty transition. Enable via systemd-units/user.txt (the .path unit; the service is on-demand). The existing SSH-shell inhibitor is kept as a backstop for non-zellij remote sessions and is now documented as such. VM (nix/vm.nix) deliberately not updated: the Ubuntu remote-dev VM never suspends, so the inhibit machinery would be inert there.