Question
Configuring a start‑up timeout for runit services in Artix Linux
Ash Indigo
0 reputation · 20 Oct 2024, 05:46 UTC
views
Loading…
0 reputation · 20 Oct 2024, 05:46 UTC
The goal is to guarantee that a runit‑supervised service that hangs in its exec command is automatically terminated after a configurable interval, preventing it from consuming CPU or memory indefinitely on a low‑traffic VPS.
However, the base‑runit metapackage does not define a documented, enforceable timeout for service start‑up scripts; runit will wait indefinitely if the exec command blocks, and the official documentation does not describe a global mechanism to impose such a limit.
It remains unclear whether a single runit configuration file can be applied to all supervised services to enforce a timeout, or if each service must be individually wrapped (e.g., with a timeout helper) and how this interacts with existing Artix packages that already ship runit log directories.
What is the recommended way to apply a uniform start‑up timeout across all runit services without modifying each package’s runit script? Does Artix provide or plan to introduce a global timeout setting for runit, or must administrators rely on external wrappers and accept the maintenance overhead?
29275 reputation · 20 Oct 2024, 10:38 UTC
There is no global configuration file or native setting in runit to enforce a startup timeout across all services. To prevent a service from hanging indefinitely during its exec command, you must wrap the execution command within each individual service's run script using a utility like timeout.
The runsv supervisor is designed for minimalism. Its primary role is to execute the run script and monitor the resulting process. If the script blocks during the execution phase, runsv simply waits for the process to either succeed or fail; it does not possess an internal timer to kill processes that take too long to initialize.
Because Artix Linux follows the upstream runit philosophy, there is no centralized "timeout.conf" or similar mechanism. Any attempt to implement a global timeout would require modifying the runsv binary itself, which is not recommended as it would be overwritten during system updates and could destabilize the init process.
The standard approach is to use the GNU timeout command. This ensures that if the service does not successfully initialize and transition to a running state within the specified window, it is terminated, allowing runit to attempt a restart or log the failure.
Example Modification:
artixlinux# Original run script line:
exec /usr/bin/my-service --options
# Modified run script line (5-second timeout):
exec timeout 5s /usr/bin/my-service --optionsrunit will see the process exit and immediately attempt to restart it. This can lead to a rapid restart loop that consumes CPU.timeout as the exec command generally allows runit to track the wrapper process. When timeout kills the child process, the wrapper exits, signaling runsv that the service has stopped.run scripts, updates to Artix packages that overwrite the service directory (/var/service/ or /etc/sv/) may revert these changes.To verify that the timeout utility is available and functioning on your VPS, run:
timeout --version
# Test a hang with a 2-second limit
timeout 2s sleep 10
# The command should exit after 2 seconds with a non-zero status.Missing Diagnostic Detail: Are you using a custom runit wrapper or a specific Artix flavor (e.g., Artix with OpenRC/Runit hybrid) that might have an additional layer of process management?
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.