如何在Linux中设置关机后的自动重启？shutdown命令与重启参数的使用方法-LINUX-PHP中文网

如何在Linux中设置关机后的自动重启？shutdown命令与重启参数的使用方法

星夢妙者

发布： 2025-09-05 12:01:01

原创

276人浏览过

最直接的方法是使用shutdown -r命令实现计划重启，如sudo shutdown -r +5指定5分钟后重启并通知用户，该命令支持取消操作（sudo shutdown -c），相比reboot或systemctl reboot更安全，适合服务器环境；后者则适用于立即重启。

如何在linux中设置关机后的自动重启？shutdown命令与重启参数的使用方法

Linux中，如果你想安排系统在某个时间点“关机”然后“自动重启”，最直接且常用的方法是利用

shutdown

登录后复制

命令配合其重启参数。说实话，“关机后的自动重启”这个说法，初听起来有点像系统完全断电后又能自己活过来，但我们这里要讲的，其实是通过

shutdown

登录后复制

命令，让Linux系统执行一次计划好的、完整的重启流程。它不是先关机再开机，而是一气呵成地从运行状态转到重新运行状态，确保所有服务都能优雅地关闭，然后系统重新启动。这通常是通过

shutdown -r

登录后复制

命令实现的，你可以指定一个具体的时间，让系统在那个时刻执行重启操作。

解决方案

要在Linux中设置计划的自动重启，我们主要依赖

shutdown

登录后复制

命令。这个命令提供了强大的灵活性，可以精确控制何时以及如何重启系统。

最基础的用法是立即重启：

sudo shutdown -r now

登录后复制

或者，你也可以使用

sudo shutdown -r 0

登录后复制

，效果一样，系统会立即开始重启流程。这里的

-r

登录后复制

参数就是告诉

shutdown

登录后复制

命令，我们不是要关机（halt），而是要重启（reboot）。

如果想在未来的某个时间点重启，比如5分钟后：

sudo shutdown -r +5 "系统将在5分钟后重启，请保存工作。"

登录后复制

这里的

+5

登录后复制

表示从当前时间算起的分钟数。双引号里的内容是给所有登录用户发送的通知消息，让他们知道系统即将重启，这在多用户或服务器环境中尤为重要。

你也可以指定一个具体的时刻，比如晚上10点（22:00）：

sudo shutdown -r 22:00 "计划维护，系统将在今晚10点重启。"

登录后复制

需要注意的是，

shutdown

登录后复制

命令的执行需要root权限，所以通常前面会加上

sudo

登录后复制

。一旦命令发出，系统会在指定时间前开始倒计时，并通知所有用户。这比直接使用

reboot

登录后复制

命令要“温柔”得多，因为它允许所有运行中的进程有时间正常结束，避免数据丢失或服务中断。

如何安全地取消一个已计划的重启任务？

有时候，计划好的重启任务可能会因为突发情况需要取消。比如，你发现某个重要服务还没有完成数据同步，或者团队决定推迟维护时间。在这种情况下，安全地取消重启任务至关重要，避免不必要的停机。

取消一个正在等待执行的

shutdown

登录后复制

命令非常简单，只需要使用

shutdown

登录后复制

命令的

-c

登录后复制

参数：

sudo shutdown -c

登录后复制

这个命令会立即撤销所有待处理的

shutdown

登录后复制

或

reboot

登录后复制

任务。执行后，系统会向所有用户广播一条消息，告知他们之前的重启或关机计划已被取消。

我个人就遇到过这样的情况，有次在测试环境不小心把生产环境的重启命令敲了进去，幸好及时发现，用

sudo shutdown -c

登录后复制

快速挽救了局面。所以，这个命令可以说是一个“后悔药”，关键时刻能派上大用场。重要的是，它不仅取消了命令本身，还会清除所有相关的通知，让系统恢复到正常运行状态，不会再有计划重启的提示。

除了

shutdown -r

登录后复制

，还有哪些命令可以实现Linux系统的重启？它们有何区别？

在Linux中，实现系统重启的命令远不止

shutdown -r

登录后复制

一个，每个命令都有其特定的使用场景和行为模式。理解这些差异，能帮助我们更灵活地管理系统。

```
reboot
```
登录后复制
命令这是最直接的重启命令，通常会立即执行重启操作。
```
sudo reboot
```
登录后复制
它通常会尝试进行一次干净的关机，然后重新启动。但在某些旧系统或特定配置下，它可能不会像
```
shutdown -r
```
登录后复制
那样提供优雅的通知和等待时间。对我而言，如果我只是想快速重启一台个人工作站，且确定没有其他用户，
```
reboot
```
登录后复制
用起来很顺手。

降重鸟
要想效果好，就用降重鸟。AI改写智能降低AIGC率和重复率。

113

查看详情
```
systemctl reboot
```
登录后复制
命令在采用
```
systemd
```
登录后复制
作为初始化系统的现代Linux发行版中（如Ubuntu 16.04+，CentOS 7+），
```
systemctl
```
登录后复制
是管理系统服务和电源状态的首选工具。
```
sudo systemctl reboot
```
登录后复制
这个命令会通过
```
systemd
```
登录后复制
来管理重启过程，通常会非常优雅地停止所有服务，然后重启系统。它在功能上与
```
shutdown -r now
```
登录后复制
或
```
reboot
```
登录后复制
类似，但它是
```
systemd
```
登录后复制
生态系统的一部分，被认为是更现代、更推荐的做法。
```
init 6
```
登录后复制
命令这是基于SysVinit系统（较旧的Linux发行版）的命令，用于切换运行级别。运行级别6就是重启。
```
sudo init 6
```
登录后复制
在
```
systemd
```
登录后复制
系统中，
```
init
```
登录后复制
命令通常被重定向到
```
systemctl
```
登录后复制
，所以
```
sudo init 6
```
登录后复制
在现代系统上可能等同于
```
sudo systemctl reboot
```
登录后复制
。不过，作为一种历史遗留和兼容性用法，了解一下也无妨。

主要区别总结：

shutdown -r
登录后复制
: 最适合计划性重启，提供倒计时、用户通知和取消功能，确保系统和应用有足够时间进行清理。
reboot
登录后复制
/
systemctl reboot
登录后复制
: 适合立即重启，通常用于维护后或配置更改后的快速重启。
```
systemctl reboot
```
登录后复制
是现代系统的推荐方式，因为它能更好地与
```
systemd
```
登录后复制
集成。
init 6
登录后复制
: 主要是历史遗留用法，在现代
```
systemd
```
登录后复制
系统中通常等同于
```
systemctl reboot
```
登录后复制
。

在选择命令时，我会根据场景来判断。需要提前通知和预留时间的，无疑是

shutdown -r

登录后复制

；如果只是我自己操作，且需要立即生效，

systemctl reboot

登录后复制

是我的首选。

在服务器环境中，计划重启时需要注意哪些潜在问题和最佳实践？

服务器环境下的计划重启，远比个人电脑复杂得多，因为这可能涉及到多用户、多个关键服务以及潜在的业务中断。我个人在管理服务器时，每次计划重启都像是在走钢丝，必须小心翼翼。

充分的通知与沟通： 这是重中之重。在重启前，必须通过邮件、即时通讯工具甚至
```
wall
```
登录后复制
命令（
```
echo "系统将在15分钟后重启" | sudo wall
```
登录后复制
）提前告知所有受影响的用户或团队成员。通知内容应包含重启时间、预计持续时间以及任何可能的影响。
保存所有重要数据和配置： 确保所有数据库事务已提交，文件已保存，配置更改已写入磁盘。有时候，我会手动触发一些服务的保存命令，比如MySQL的
```
FLUSH TABLES WITH READ LOCK;
```
登录后复制
（当然这需要小心使用并解锁）。
检查关键服务状态： 在重启前，花点时间确认哪些服务正在运行，尤其是那些对业务至关重要的服务（如数据库、Web服务器、消息队列等）。了解它们的启动顺序和依赖关系，以便重启后能及时验证。我通常会有一个清单，列出重启后需要检查的服务和端口。
自动化脚本的应用： 对于复杂的服务器环境，可以编写预重启和后重启脚本。
- 预重启脚本（Pre-reboot script）：用于优雅地关闭某些特定服务，备份关键数据，或者向监控系统发送维护模式通知。
- 后重启脚本（Post-reboot script）：用于验证服务是否正常启动，运行健康检查，并向监控系统发送恢复正常运行的通知。
选择合适的维护窗口： 尽量选择业务量最少的时间段进行重启，比如深夜或周末，以最小化对用户的影响。这需要与业务团队紧密协作。
日志审查： 重启完成后，立即检查系统日志（如
```
/var/log/syslog
```
登录后复制
、
```
/var/log/messages
```
登录后复制
或使用
```
journalctl
```
登录后复制
）以及各应用服务的日志，确认所有服务都已正常启动，没有出现异常错误。有时候，一些服务看似启动了，但实际上内部组件可能存在问题，日志会揭示这些隐患。
避免在繁忙时段操作： 这是一个经验之谈。我在一次高峰期尝试重启一个辅助服务，结果连锁反应导致主服务也受到影响，教训惨痛。非必要，绝不在业务高峰期进行任何可能导致中断的操作。