feat: prevent host sleep during active tasks (#2264)

This commit is contained in:
Carlos Florêncio
2026-08-05 18:24:14 +01:00
committed by GitHub
parent ad70426d46
commit fef76fda57
52 changed files with 3775 additions and 39 deletions
+29
View File
@@ -27,6 +27,35 @@ Kandev does not currently provide a user-login boundary for the web application,
See [Desktop app](desktop-app.md), [CLI](cli.md), [Run as a service](run-as-a-service.md), [Docker](docker.md), and [Kubernetes](k8s.md) for mode-specific prerequisites and commands.
## Prevent host sleep during active tasks
Administrators can open **Settings > General > Task Actions** and enable
**Prevent host sleep while tasks run**. The install-wide setting is off by
default and is saved with the Kandev database. It applies only to the machine
running the backend; it does not change executor or node power policy.
When enabled, Kandev holds one host sleep-prevention request while any task
session is `STARTING` or `RUNNING`. It releases the request when the last such
session reaches `WAITING_FOR_INPUT`, `IDLE`, or a terminal state, when an
administrator disables the setting, and during backend shutdown. Missed session
events are repaired by periodic reconciliation against the session repository.
The request prevents idle system sleep but does not keep the display awake or
override an explicit user sleep action, lid-close behavior, shutdown, low-power
emergency, or another administrator/platform policy. It is supported through
macOS `caffeinate`, Windows execution state, and Linux `systemd-logind` over the
system D-Bus. A missing or denied Linux system bus, an unavailable service, or
another native failure is shown in the setting status and never blocks task
execution.
Do not enable this setting by default for Docker, Kubernetes, remote-executor,
or always-on deployments. A backend inside a container or pod cannot inhibit
sleep on the physical node, and an SSH or other remote executor runs on a
different host. Those deployments should use their normal host power and
availability policy instead. Enabling the preference is safe when moving the
database between hosts: Kandev reacquires a native request only after startup
if the new backend can provide it and a working task still exists.
## Health and readiness
Use the top-level readiness endpoint for supervisors and probes: