Schedule a Safe Linux Shutdown with systemd's shutdown Command

You will schedule, inspect and cancel a Linux shutdown using the systemd compatibility command shutdown. The examples are for the installed systemd-sysv package, version 255.4-1ubuntu8.17, whose manual page identifies the interface as systemd 255. Allow about ten minutes. You need a shell and permission to manage the machine; the final power-off, halt or reboot normally requires elevated privileges.

1. Check which shutdown you have

Confirm that the command resolves to the systemd interface and inspect its local help:

$ command -v shutdown
/usr/bin/shutdown
$ dpkg-query -W -f='${Package} ${Version}\n' systemd-sysv
systemd-sysv 255.4-1ubuntu8.17
$ shutdown --help
shutdown [OPTIONS...] [TIME] [WALL...]

Shut down the system.

The command is a compatibility interface backed by /usr/bin/systemctl. For direct, unambiguous operations, systemd also provides systemctl poweroff and systemctl reboot. This guide concentrates on shutdown because it adds scheduling, warnings and cancellation in one interface.

2. Read the time syntax before scheduling

The first non-option argument is the time. now means immediate action and is an alias for +0. A relative time such as +15 means 15 minutes from now. An absolute time such as 23:30 uses the 24-hour clock. If you omit the time, systemd's shutdown implies +1, so do not leave it out accidentally.

A wall message must come after a time argument. This is valid syntax, although the command is still a real shutdown request:

$ sudo shutdown --poweroff +15 "Maintenance: the server will power off in 15 minutes."

sudo is required here because this changes machine state. The message is sent to logged-in users before the action. When a timed shutdown is scheduled, /run/nologin is created five minutes before the machine goes down so that new logins are refused.

3. Choose the action explicitly

Use a long option when the outcome needs to be obvious during review:

• --poweroff powers the machine off. This is the default action.
• --halt halts the machine without selecting power-off.
• --reboot restarts the machine.

The short -h option is a compatibility wrinkle. It means power-off unless --halt has also selected halt; it does not mean help. Prefer --poweroff, --halt or --reboot in scripts and runbooks.

For a visible dry run of the warning path, use -k. It sends the wall message but does not halt, power off or reboot:

$ sudo shutdown -k +5 "Test warning only: no shutdown will occur."

Checkpoint: -k is not a scheduled shutdown to cancel. It is a warning-only request. Do not remove it from a test command unless you have deliberately chosen the real action.

4. Inspect a pending shutdown

Before changing a maintenance plan, ask whether a shutdown is already pending:

$ shutdown --show
Shutdown scheduled for ...

The exact date and time depend on the machine clock. If no shutdown is pending, the command reports that there is no scheduled action. The --show option was added in systemd version 250, so it is available in the installed version 255.

If you need to check the clock before using an absolute time, run:

$ date '+%Y-%m-%d %H:%M:%S %Z'
2026-09-27 14:30:00 BST

The displayed values are examples. Use the output from your own host; an incorrect timezone or a stale remote session is a common cause of apparently early or late maintenance.

5. Cancel before the deadline

Cancel a pending timed shutdown with -c:

$ sudo shutdown -c
Shutdown cancelled.

Cancellation applies to a shutdown invocation with a time other than now or +0. It does not undo a power-off, halt or reboot that has already started. If you are unsure whether the cancellation reached the right host, run shutdown --show afterwards and check the terminal or monitoring output.

Do not use shutdown -c as a substitute for investigating an unexpected request. Review the pending action, identify the operator or automation that created it, and record the change in the maintenance log.

6. Avoid the common failure modes

If a command fails, first check that you are on the intended host and that your account can use sudo. A remote terminal, a production shell and a test shell can look nearly identical. Use hostname and date before a disruptive command when there is any doubt.

Do not put a message before the time: shutdown "message" +15 does not follow the documented argument order. Do not assume an omitted time means "show me what would happen"; it schedules an action one minute ahead. Do not parse a wall message as proof that the machine stopped: warnings can be sent by -k without any shutdown.

If the requirement is single-user rescue mode, use sudo systemctl rescue instead. Older init systems used shutdown for that meaning, but this systemd interface defaults to power-off, not rescue mode.