Power States

Shutting down or rebooting changes the availability of the entire system. Before acting, confirm the target host, obtain authorization, warn connected users, and make sure important writes, backups, and maintenance tasks can finish. On a remote system, preserve an independent console or recovery path in case the machine does not return.

Powering Off Safely

On a systemd-based distribution, request an orderly power-off with:

$ sudo systemctl poweroff

The traditional shutdown interface is also widely available:

$ sudo shutdown -h now

An orderly shutdown asks services to stop, unmounts filesystems, and then changes the machine's power state. Do not treat a forced reboot or the physical power switch as an ordinary shortcut; either can interrupt writes and leave data or services inconsistent.

Scheduling and Cancelling a Shutdown

Give users and workloads time to prepare by scheduling the operation. The +m form means a number of minutes from now:

$ sudo shutdown -h +4

This schedules a halt or power-off in four minutes and sends warnings to logged-in users. If the maintenance is postponed, cancel a pending shutdown before its deadline:

$ sudo shutdown -c

Do not assume that a warning makes the operation safe. Check active sessions and system-specific workloads, and follow the service or cluster's documented drain procedure when one exists.

Rebooting the System

Use an orderly reboot when the machine must stop and start again:

$ sudo systemctl reboot

Equivalent compatibility commands commonly include:

$ sudo shutdown -r now
$ sudo reboot

Before rebooting, verify that encrypted disks, boot configuration, networking, and required services can recover without the current interactive session. Coordinate failover or workload migration first when other systems depend on the host.

Distinguishing Halt from Power-Off

halt, poweroff, and reboot may be compatibility front ends to the init system, but their requested end states differ. A halt stops normal system operation; depending on the platform and implementation, it might leave power supplied. A power-off additionally requests that supported hardware remove power. Prefer the command that names the intended outcome, and consult the local manual because compatibility behavior can vary.

Verifying the Outcome

For a scheduled operation, confirm that users received notice and that critical work has drained. After a reboot, verify the expected kernel and boot state, failed units, application health, storage mounts, network reachability, and recent boot logs. A successful login alone does not prove that the whole service recovered.

$ uptime
$ systemctl --failed
$ journalctl -b -p warning

These are starting points; use application-native health checks for the actual workload.

Summary

You can now change Linux power states with preparation, clear intent, and verification.

1. Confirm the target, impact, authorization, and recovery path.
2. Use orderly power-off or reboot commands for normal operations.
3. Schedule a shutdown when users and workloads need warning.
4. Cancel a pending shutdown when the maintenance plan changes.
5. Verify system and application health after the machine returns.