| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/<pid>/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.
|
|
|
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.
|
sommerfeld