在Linux命令行下，计划关机或重启主要依赖于两个强大的工具：
at和
cron。简单来说，如果你需要执行一次性的、未来某个时刻的关机或重启操作，
at是你的首选；而对于周期性的、重复的维护任务，比如每周重启一次服务器，那么
cron就是不可或缺的。我个人觉得，理解并熟练运用这两个工具，是每个Linux系统管理员，甚至是高级用户，都应该掌握的基本功，它们能帮你省去不少手动操作的麻烦，尤其是在远程管理服务器时。
解决方案
使用 at
命令进行一次性关机/重启
at命令允许你在指定的时间执行一次性任务。这对于那些临时的维护窗口或者需要特定时间点执行的关机操作非常有用。
-
确认
atd
服务正在运行：at
命令依赖于atd
服务。你可以通过以下命令检查其状态并启动它（如果需要）：sudo systemctl status atd sudo systemctl start atd sudo systemctl enable atd # 确保开机自启动
-
调度关机任务： 假设你想在10分钟后关机：
echo "sudo shutdown -h now" | at now + 10 minutes
或者，如果你想在晚上10点关机：
echo "sudo shutdown -h now" | at 22:00
这里，
shutdown -h now
是立即关机的命令。你也可以使用reboot
进行重启。 -
查看和取消任务： 查看当前所有待执行的
at
任务：atq
你会看到任务的编号。例如，如果任务编号是
1
，你可以这样取消它：atrm 1
使用 cron
命令进行周期性关机/重启
cron是Linux下用于周期性任务调度的工具，非常适合那些需要定期执行的关机或重启操作。
-
编辑
crontab
文件： 每个用户都有自己的crontab
文件，你可以通过以下命令编辑它：crontab -e
这会打开一个文本编辑器（通常是
vi
或nano
），你可以在其中添加你的调度任务。 -
cron
任务的语法：cron
任务的格式是：分 时 日 月 周 命令
- 分 (Minute): 0-59
- 时 (Hour): 0-23
- 日 (Day of Month): 1-31
- 月 (Month): 1-12
- 周 (Day of Week): 0-7 (0或7代表周日，1代表周一)
- 命令 (Command): 要执行的命令
特殊字符：
*
: 匹配所有可能的值。,
: 列出多个值。例如1,3,5
表示1、3、5。-
: 指定一个范围。例如1-5
表示1到5。/
: 指定步长。例如*/5
表示每5分钟。
-
调度关机/重启任务示例：
-
每天凌晨3点重启：
0 3 * * * /usr/sbin/reboot
这里我特意使用了
/usr/sbin/reboot
的完整路径，这是一个好习惯，可以避免PATH
环境变量问题。 -
每周六晚上11点半关机：
30 23 * * 6 /usr/sbin/shutdown -h now
-
每月1号凌晨2点重启：
0 2 1 * * /usr/sbin/reboot
注意： 对于需要
sudo
权限的命令（如shutdown
或reboot
），最好是编辑root
用户的crontab
。你可以通过sudo crontab -e
来做到这一点。 -
为什么我们需要计划关机或重启？
在我看来，计划性的关机或重启不仅仅是为了省电或者让机器“休息一下”那么简单。它在系统维护和稳定性方面扮演着至关重要的角色。
一个主要原因是为了系统资源的优化和释放。长时间运行的系统，即使没有明显的内存泄漏，也可能因为各种应用程序的缓存、临时文件、或者一些不那么完美的程序行为，导致内存碎片化、文件句柄累积等问题，这最终会影响系统性能。定期重启就像给系统做了一次彻底的“大扫除”，清除了所有这些累积的负担，让系统回到一个干净、高效的状态。我曾经遇到过一些老旧的服务器，如果不是每周强制重启一次，运行几天就会变得异常缓慢，响应迟钝。
其次是安全更新和补丁的生效。很多Linux内核或核心服务的安全更新，都需要重启系统才能完全生效。如果你只是安装了补丁而不重启，那么这些漏洞可能依然存在。计划重启可以确保这些关键的安全更新能够及时、有效地应用，从而提高系统的安全性。当然，这需要配合自动化更新机制一起使用。
还有就是预防性维护。对于一些特定的应用场景，比如数据库服务器或者一些计算密集型服务，定期重启可以避免一些潜在的、难以追踪的稳定性问题，比如某个服务偶尔出现的死锁，或者某个驱动程序的微小内存泄漏。虽然这听起来有点像是“治标不治本”，但在某些情况下，它确实是最经济有效的解决方案。
最后，节约能源也是一个实际的考量。对于非24/7运行的服务器或者工作站，在非工作时间关机可以显著降低电费开支，也算是为环保出了一份力。
使用at
命令进行一次性任务调度有哪些常见陷阱？
虽然
at命令用起来很直接，但我在实际使用中也踩过一些坑，这些“陷阱”如果不注意，可能会让你以为任务没执行或者执行失败。
一个最常见的坑就是权限问题。比如你用普通用户身份调度了一个
sudo shutdown -h now的任务。
at任务在执行时，默认是以调度任务的用户身份运行的。如果你的命令需要
root权限，但你没有在
at任务中提供
sudo密码（
at任务无法交互式地获取密码），那么这个命令就会失败。正确的做法是，确保
sudo命令已经被配置为不需要密码（通过
visudo配置
NOPASSWD），或者直接切换到
root用户 (
sudo su -) 来调度需要
root权限的
at任务。
另一个问题是环境差异。
at任务执行时的环境通常比你当前登录的Shell环境要“干净”得多，这意味着
PATH环境变量可能不包含你所有常用命令的路径。我曾经遇到过一个脚本，在Shell里跑得好好的，放到
at里就报错找不到命令。解决办法是，在
at任务的脚本中，使用命令的完整路径，比如
echo "/usr/sbin/shutdown -h now" | at now + 5 minutes，而不是仅仅
shutdown -h now。
输出和错误处理也是一个需要注意的地方。
at任务在后台运行，它的标准输出和标准错误默认会通过邮件发送给调度任务的用户（如果系统配置了邮件服务的话）。如果你的系统没有配置邮件服务，或者你没有检查邮件的习惯，那么任务执行失败的错误信息你可能就错过了。一个好的实践是，将
at任务的输出重定向到文件，比如
echo "sudo /path/to/my_script.sh > /var/log/my_at_job.log 2>&1" | at now + 1 hour，这样即使没有邮件，你也能从日志文件中找到线索。
最后，别忘了atd
服务。如果
atd服务没有运行，那么你调度再多的
at任务也只是存在队列里，永远不会被执行。这是最基础也最容易被忽视的一点。
cron
任务调度在实际生产环境中应注意哪些细节？
cron在生产环境中是核心工具，但要用好它，避免一些意想不到的麻烦，需要注意的细节可不少。
首先，命令的完整路径是重中之重。就像
at任务一样，
cron任务执行时的环境通常也很有限。我见过太多因为
crontab里只写了
python myscript.py而不是
/usr/bin/python /path/to/myscript.py导致任务失败的案例。永远使用命令的绝对路径，包括脚本本身和脚本中调用的任何外部命令。这能有效避免
PATH环境变量带来的问题。
其次是输出重定向和日志记录。
cron任务的任何标准输出和标准错误，默认都会尝试通过邮件发送给
crontab的所有者。在生产环境中，这可能导致你的邮箱被大量的
cron邮件塞满，或者更糟的是，如果邮件服务配置不当，你根本收不到任何错误通知。最佳实践是，将所有输出重定向到日志文件：
0 3 * * * /usr/sbin/reboot > /var/log/reboot_cron.log 2>&1
这样，所有的成功或失败信息都会被记录下来，方便你日后审计和排查问题。你也可以在
crontab文件的开头设置
MAILTO=""来禁用邮件通知，或者指定一个特定的邮箱地址。
并发和重叠任务是另一个需要仔细考虑的问题。如果你有一个任务需要运行很长时间，并且它被设置为每小时运行一次，那么有可能会出现上一个任务还没结束，下一个任务又开始了，导致资源争抢或者数据不一致。对于这类任务，可以考虑在脚本内部加入锁机制（比如使用
flock命令或者简单的文件锁），确保同一时间只有一个实例在运行。
系统用户权限也需要明确。通常，涉及系统级别的关机或重启，最好是编辑
root用户的
crontab(
sudo crontab -e)。如果你用普通用户调度了需要
root权限的命令，它会失败，除非该命令在
sudoers文件中被配置为允许该用户无密码执行。
错误处理和健壮性是衡量一个
cron任务质量的关键。你的脚本是否能在遇到错误时优雅地退出？是否能记录下错误信息？例如，在重启服务之前，你可能想检查一下服务是否真的在运行，或者在关机前先确保所有关键数据都已经同步到磁盘。
最后，测试是必不可少的。不要在生产环境直接上线一个新的
cron任务。先在一个测试环境或者通过手动执行的方式，验证你的命令或脚本是否能正常工作，并且在预期的结果下完成。对于
cron任务，你可以通过将时间设置在几分钟之后，然后观察系统行为来测试。
