fix: never suspend the appliance#25
Open
bpmct wants to merge 3 commits into
Open
Conversation
The box is an always-on appliance (Coder server + k3s) reached over the
LAN and a *.try.coder.app tunnel. A suspend drops the NIC, so the
machine silently falls off the network — no mDNS, no SSH, tunnel dead —
until someone physically wakes it.
The shipped image runs a KDE desktop (Sleep action + power-key handling)
and a stray `systemctl suspend` / Suspend() D-Bus call would do the
same. Mask the sleep/suspend/hibernate/hybrid-sleep targets so all of
those paths become no-ops, and set logind to ignore the power/suspend
keys and idle. Hardening, not a fix for one specific trigger — an
appliance simply should not be suspendable.
Verified with nixos-rebuild dry-build: emits
unit-{sleep,suspend,hibernate,hybrid-sleep}.target-disabled.
Drop the broad sleep/hibernate/hybrid-sleep target masking and the power-key/lid/idle handlers. Block only suspend: mask suspend.target and ignore the suspend key. The single concern is the appliance not suspending itself off the network; everything else is left at defaults. Verified with nixos-rebuild dry-build: emits unit-suspend.target-disabled.
Hibernate drops the NIC just like suspend, so block it too. Mask
suspend, hibernate, and hybrid-sleep targets and ignore the suspend/
hibernate keys. Idle/lid/power-key handling stays at NixOS defaults.
Verified with nixos-rebuild dry-build: emits
unit-{suspend,hibernate,hybrid-sleep}.target-disabled (sleep.target
itself is left enabled).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The box is an always-on appliance (Coder server + k3s) reached over the LAN and a
*.try.coder.apptunnel. A suspend drops the NIC, so the machine silently falls off the network — no mDNS, no SSH, tunnel dead — until someone physically wakes it.The shipped image runs a KDE desktop (which exposes a Sleep action and reacts to the power key), and a stray
systemctl suspend/Suspend()D-Bus call would do the same. This bit me: a box went unreachable, and the journal of the prior boot showedlogind: The system will suspend now!→Performing sleep operation 'suspend'with the NIC dropping its DHCP lease right after — a deliberateSuspend()via logind, not an idle timeout (it is a desktop chassis, no lid; logind idle defaults toignore).Fix
Mask the sleep targets so every suspend path (desktop Sleep, power key,
systemctl suspend,Suspend()D-Bus) becomes a no-op, and tell logind to ignore the keys/idle:This is hardening, not a fix for one specific trigger — an appliance simply should not be suspendable.
Validation
nixos-rebuild dry-build --flake /etc/nixos-repoemitsunit-{sleep,suspend,hibernate,hybrid-sleep}.target-disabledand a rebuiltetc-systemd-logind.conf.