Server Power Action
Servers
Server Power Action
POST
Server Power Action
Controls the power state of a server. This endpoint triggers power actions asynchronously and returns immediately.
Authentication
Requires the Wings authentication token in theAuthorization header:
Path Parameters
string
required
The UUID of the server
Request Body
string
required
The power action to perform. Must be one of:
start- Start the serverstop- Stop the server gracefullyrestart- Restart the serverkill- Forcefully terminate the server (SIGKILL)
integer
default:30
Number of seconds to wait for a lock on the power action (0-300). Defaults to 30 if not provided or out of range.
Response
Returns202 Accepted when the power action has been queued for processing.
Error Responses
Cannot start or restart a suspended server.
The requested server does not exist on this Wings instance.
The power action provided was not valid.
Behavior
Power Action Locking
- All actions except
killacquire an exclusive lock to prevent concurrent power actions wait_secondscontrols how long to wait for the lock (default: 30 seconds)killaction attempts to acquire lock but proceeds even if it fails
Action Details
start- Only works if server state is
offline - Runs pre-boot checks (sync, disk space, permissions)
- Suspended servers are blocked
- Waits up to 10 minutes for graceful shutdown
- Uses terminate signal if graceful shutdown fails
- Combines stop + start
- Waits for complete shutdown before starting
- Suspended servers are blocked
- Sends SIGKILL to immediately terminate the process
- Does not wait for locks (bypasses lock contention)
- Use for stuck or unresponsive servers
Pre-boot Process (start/restart)
- Syncs server configuration with Panel
- Checks suspension status
- Syncs environment variables and resource limits
- Verifies disk space availability
- Updates configuration files
- Sets file permissions (if enabled in config)
Example Requests
Start Server
Restart Server with Custom Wait Time
Kill Server
Example Response
Notes
- Power actions run asynchronously in the background
- Use websockets to monitor actual state changes
- Errors during async execution are logged but not returned to the API caller
- Multiple power actions are serialized via exclusive locking
- The
killaction bypasses most safety checks and should be used sparingly
Source Reference
Implemented inrouter/router_server.go:53 and server/power.go:56