Ubuntu每天23点自动关机:cron与systemd定时任务配置详解

发布时间:2026/10/22 4:57:42

Ubuntu每天23点自动关机:cron与systemd定时任务配置详解 最近有个朋友问我他办公室那台Ubuntu电脑能不能做到每天23:00自动关机省得人下班走了机器还亮一晚上。这种需求其实很常见开发机、打印服务器、宿舍里的个人电脑甚至机房里的某台测试设备都可能需要“到点就关”的能力。很多人第一反应是“这还不简单设个定时任务就行”但真上手会发现里面藏着不少细节shutdown命令的参数、cron的权限问题、时区差异、systemd timer的配置方式每一步都可能踩坑。这篇文章就专门讲清楚“Ubuntu系统每天定时23:00关机”这件事。我不只给你一个能直接用的配置还会把方案选型、执行原理、排查方法都讲透。无论你是刚接触Linux的新手还是已经用过cron的老手都能在这里找到适合自己的做法并且理解为什么这样写、背后是什么逻辑。1. 需求分析与方案选型1.1 这个需求到底在什么场景下出现定时关机Scheduled Shutdown表面上是个非常简单的功能但背后的场景差异很大。第一种场景是办公电脑节能。很多公司里员工下班后电脑不关显示器关了但主机还在跑。定时23:00关机可以让主机自动断电既省电费也减少设备损耗。这一类需求通常希望“不打扰、静默执行”最好在下班后还能给加班的同事留出缓冲时间所以23:00这个点选得挺考究。第二种场景是服务器或实验室设备的强制维护。比如某台设备需要在夜间停止对外服务或者测试环境需要在固定时间断电重启。这类场景对准确度要求高而且往往不能依赖人工手动操作必须由系统自己完成。第三种场景是个人电脑的“防熬夜”功能很多人为了强迫自己按时睡觉会设置一个到点强制关机的规则。不同场景对方案的要求不一样。个人电脑可能更关心“关机前要不要提醒”服务器更关心“任务是否一定能执行”。所以我在下面给出了两套主流做法cron方案和systemd timer方案分别满足不同偏好。1.2 三种主流做法对比在Linux系统里定时执行任务的选择其实不少但主流就是这三样cron、systemd timer、at。at命令是用来“安排一次性的定时任务”的比如“5分钟后重启”但它不适合做周期性的每日关机。如果你明确是“每天23:00”那at就需要每天手动加一次任务根本不实用。cron是Unix/Linux系统里最经典的任务调度器几乎所有发行版都支持配置简单一行crontab就能搞定。它适合做“分钟级粒度的重复任务”对绝大多数定时关机需求来说是第一选择。systemd timer是systemd体系里的任务调度组件Ubuntu 16.04之后系统默认就带。它比cron更“现代化”时间格式更像自然语言日志记录更规范还支持错过时间后的策略选择。缺点是学习曲线稍微陡一点配置需要写两个文件。我把这三个方案放在一张表里对比方案学习成本可靠性日志可查性适用场景cron shutdown低高中日志在syslog大多数Linux服务器和桌面systemd timer中高高journalctl统一查追求可维护性的现代系统at shutdown极低中低一次性任务不适合周期执行如果你只是想要“快速搞定以后忘掉它”选cron就够了。如果你想把定时任务做得更规范方便以后排查和扩展选systemd timer。下文我会把这两套方案都写清楚。2. 方案一cron shutdown 快速实现每日23点关机2.1 先搞清楚shutdown命令的几个参数在写定时任务之前必须先弄明白shutdown命令本身。很多人在第一步就写错了命令导致定时任务执行时报错或者根本没有效果。最常用的关机命令是shutdown -P now意思是“立即关闭系统并切断电源”。参数-Ppoweroff表示关电源如果不带这个参数默认可能会进入其他运行级别行为会很奇怪。在Ubuntu上安全的写法是sudo shutdown -P now还有一种写法是shutdown -h now-h表示halt在部分系统上也会关机但效果可能不如-P彻底所以我个人更推荐-P。另外一定要特别注意shutdown命令还可以接受一个“时间参数”比如sudo shutdown -P 23:00意思是安排系统在23:00关机。这个写法在命令行直接操作时很方便系统会提前5分钟给所有登录用户发送“系统即将关机”的警告消息。但在cron任务里这个写法就要小心了。如果你在cron里写的是0 23 * * * /sbin/shutdown -P now那意思是“23:00整准时执行关机命令”这是正确的。如果你写的是0 23 * * * /sbin/shutdown -P 23:00那cron在23:00执行时又会让shutdown再调度一次“23:00关机”。由于执行瞬间已经是23:00了这个调度通常也会立即生效但存在几秒到几十秒的竞态风险不推荐这么写。还有一点值得记一下取消一个已经调度的关机任务用shutdown -c。比如你临时不想关机了执行sudo shutdown -c就能取消。2.2 用crontab创建每日23点的定时任务cron的配置入口有两个当前用户的crontab和root用户的crontab。因为关机操作需要root权限所以我推荐直接用root的crontab这也是全系统生效的做法。第一步编辑root的cron任务sudo crontab -e第一次执行时系统会问你想用哪个编辑器通常选nano新手友好或者vim老手习惯都可以。第二步在文件末尾加上一行0 23 * * * /sbin/shutdown -P now这行cron表达式的含义是每天的第23小时、第0分钟执行后面的命令。五个字段从左到右分别是“分、时、日、月、周”顺序特别容易写反很多人把“0 23”写成“23 0”结果变成了23分钟时执行一次坑得很。第三步保存退出。如果是nano按CtrlO保存再按CtrlX退出如果是vim输入:wq回车。第四步确认任务写进去了sudo crontab -l看到刚才那行就说明任务已经注册成功。这里有一个细节值得展开为什么我写的是/sbin/shutdown的绝对路径而不是直接写shutdown因为cron执行任务时使用的环境变量非常精简PATH通常只有/usr/bin:/bin这种基础路径而shutdown命令在Ubuntu上位于/sbin/shutdown不一定在默认PATH里。如果不写绝对路径定时任务可能报“command not found”却不知道去哪查。你可以用which shutdown命令查看自己系统上shutdown的绝对路径在Ubuntu上通常是/usr/sbin/shutdown或/sbin/shutdown把查到路径填进去即可。2.3 确认cron服务在运行任务写完之后还需要确认cron服务本身是启动状态。Ubuntu用systemd管理服务所以检查命令是sudo systemctl status cron如果看到状态是active (running)说明cron在正常工作。如果发现服务没有启动那就手动启动并设为开机自启sudo systemctl enable --now cron这个--now参数的意思是“立刻启动同时设置开机自启”比分开两条命令写更省事。另外你还可以查看cron的执行日志来验证任务是否真的跑了。在Ubuntu上cron日志默认写到/var/log/syslog可以这样查询grep CRON /var/log/syslog不过更推荐用journald来查journalctl -u cron如果你看到类似CMD (/sbin/shutdown -P now)的记录说明定时任务确实被执行了。这个排查习惯很重要遇到“任务没生效”时日志是第一个调查对象。3. 方案二systemd timer 实现每日23点关机3.1 为什么还要用systemd timercron方案够简单但有几个地方让人觉得不够爽cron表达式那五段数字过两天再看就忘了什么意思日志分散在syslog里不太醒目cron对“任务是否必须要跑”没有太多策略控制。systemd timer就不一样。它用两个文件组成一个任务单元一个.service文件定义“要执行什么”一个.timer文件定义“什么时候执行”。时间格式用的是类似OnCalendar*-*-* 23:00:00的写法一读就懂任意年任意月任意日23点整。systemd timer还有一个cron没有的能力Persistent选项可以决定“如果任务时间点错过了一次开机后要不要补执行”。这个对定时关机来说非常关键——稍后我会专门讲怎么用安全。3.2 创建shutdown.service单元文件第一步创建service文件sudo vim /etc/systemd/system/poweroff-at-night.service内容如下[Unit] DescriptionPower off at night scheduled task [Service] Typeoneshot ExecStart/sbin/shutdown -P now注意Typeoneshot这个配置。它告诉systemd这个服务不是持续运行的后台程序而是一次性执行完毕的任务比较符合“执行关机”这种动作的特性。ExecStart后面依然要写shutdown的绝对路径。你自己系统上是什么路径就用which shutdown查出来的结果。3.3 创建shutdown.timer单元文件第二步创建timer文件sudo vim /etc/systemd/system/poweroff-at-night.timer内容如下[Unit] DescriptionTimer to power off every day at 23:00 [Timer] OnCalendar*-*-* 23:00:00 Persistentfalse [Install] WantedBytimers.targetOnCalendar*-*-* 23:00:00是systemd的日历时间表达式含义是每一天的23:00:00。这个格式非常直观比cron的五字段更接近人类语言。3.4 启动并验证定时器第三步重新加载systemd配置并启动定时器sudo systemctl daemon-reload sudo systemctl enable --now poweroff-at-night.timer第一条命令让systemd重新读取新增的单元文件第二条命令把timer设为开机自启并立即激活。第四步验证定时器状态sudo systemctl status poweroff-at-night.timer sudo systemctl list-timerslist-timers输出里能看到每个定时器的下次触发时间NEXT和最近触发时间LAST。如果你看到poweroff-at-night.timer的NEXT时间是第二天的23:00说明配置成功。想看这个任务到底有没有执行可以用journalctl -u poweroff-at-night.service日志里会记录service的启动和停止情况这比cron的日志清爽多了。取消这个定时任务也很简单一条命令sudo systemctl disable --now poweroff-at-night.timer如果你想彻底删掉再把两个单元文件删掉即可。这里我要重点强调一下Persistentfalse的选择。Persistenttrue的意思是“如果原定的触发时间点被错过比如当时机器没开机那么下次开机时立即补执行”。对“备份”“数据同步”这类任务来说这个功能很棒但对“关机”来说非常危险。假设你出差一周电脑是关着的周一早上9点开机准备干活结果systemd发现上周日23:00的关机任务没执行按Persistenttrue的逻辑马上执行关机命令——刚开机就瞬间关机资料都没来得及看这绝对是你不想遇到的。所以我明确建议用Persistentfalse保证“错过就错过绝不补刀”。4. 进阶技巧让定时关机更顺手4.1 关机前如何提醒当前用户直接关机其实有点“粗暴”。如果23:00时你还在电脑前忙活系统突然掉电谁都会崩溃。即便系统会在关机前通知默认的shutdown警告也不够醒目。所以最好加一个“关机前5分钟弹窗提醒”的机制。cron方案和systemd方案都能实现思路是把原来的23:00关机改成“先弹提醒再执行关机”。这里不要用两个独立的定时任务去拼太脆了最简单的做法是利用shutdown命令自带的时间参数。如果你追求简单可以直接把cron任务改成如下两条55 22 * * * DISPLAY:0 notify-send 系统将在5分钟后关机请保存工作 ; /sbin/shutdown -P 23:00前提是你用的是桌面版Ubuntu并且需要知道当前用户的DISPLAY编号。这个方案把“提醒”和“调度关机”合并成一条任务22:55弹一次通知然后由shutdown在23:00执行真正的关机省心。如果你用的是GNOME桌面还可以用zenity --warning --text系统即将关机来代替notify-send效果差不多看个人喜好。4.2 时区与时间同步问题这是定时任务最常见的隐性杀手系统的时区不对。Ubuntu安装时如果选的不是国内时区或者服务器默认是UTC时区你的“23:00关机”可能变成“UTC 23:00关机”换算成北京时间就是第二天早上7点关机。这完全是两码事。检查方法很简单timedatectl status输出里Time zone一栏如果显示Asia/Shanghai那没问题。如果显示的是UTC或者别的时区执行sudo timedatectl set-timezone Asia/Shanghai改完再timedatectl status确认一次。顺带说一句cron和systemd timer用的都是系统当前的本地时区所以只要系统时区对了两者都不需要单独配置。另外如果你的系统时间有偏差还需要确认时间同步服务在运行sudo timedatectl set-ntp true这个命令会启用systemd-timesyncd服务让系统自动通过NTP服务器校准时间减少“因为系统时钟走得慢导致定时任务不准”的问题。4.3 和“定时开机”联动使用定时关机的进阶玩法是配合“定时开机”实现夜间自动关机、早晨自动开机的完整闭环。定时开机不是操作系统层面的功能而是BIOS/UEFI里的功能通常叫RTC Wake或Power On by RTC。你可以在BIOS设置里指定每个工作日早晨8点通电然后在操作系统里设置每天23:00关机这样这台机器就实现了“晚上睡觉、早上自动起来工作”的无人值守周期。这个玩法在机房、实验室或者需要长期运行的设备上特别实用。有一点要注意定时开机依赖主板时钟如果你的主板电池没电了RTC时间会丢失定时开机就失效了。所以建议同时开启NTP时间同步让系统在开机后自动纠正时间偏差。4.4 快速测试定时任务的方法不要去傻等23:00验证任务手动改时间测试更快。用cron举例你可以先把crontab改成2 * * * * /sbin/shutdown -P now意思是“每小时的第2分钟关机”。保存后等2分钟机器顺利关机说明这条链路没问题。测完之后再改回0 23 * * *。用systemd timer测试更简单直接把OnCalendar改成*-*-* 00:02:00或者更暴力的方式触发的service文件保持不变只把OnCalendar改成几小时后然后看systemctl list-timers有没有正确地计算下次时间。注意测试时别把系统玩崩了就行。5. 常见问题排查与实操避坑5.1 任务到了23:00但没有反应这是最常遇到的问题。按照我自己的排查顺序一般是这样第一步确认cron服务在运行。用sudo systemctl status cron查看没启动就启动。第二步确认crontab条目真实存在。用sudo crontab -l不要只查看你登录用户自己的crontab因为关机任务在root的crontab里。第三步看cron日志确认任务有没有被调度执行。用grep CRON /var/log/syslog查。如果你在日志里看到了CMD记录说明cron执行了命令那问题大概率出在shutdown命令本身——比如路径写错、权限不够或者系统当时挂起了。第四步检查机器在23:00时是不是处于休眠或者关机状态。如果电脑当时已经休眠了所有定时任务都不会触发因为CPU和内存都没在工作。这是很多人忽略的定时任务依赖系统运行不是靠主板独立芯片调度。我发现文档里“系统已经关机/休眠”这个原因格外容易被忽略。cron和systemd timer都不能“唤醒”已经关机的电脑。定时关机任务只保证“机器开着的时候到点自动关”并不能保证“机器关了之后再把它叫醒”这是主板层的工作。5.2 触发了关机命令但系统没有真正断电这种情况比较少见但一旦遇到就很让人头疼。常见原因有两个一个是shutdown参数不对。如果你写的是shutdown -h now在某些系统上会执行halt而不是poweroff最终表现就是系统卡在“已关机但电源还通电”的状态。解决办法是把参数统一改成-P。另一个是系统里还有其他会话或者服务阻止了关机。在桌面版Ubuntu上如果有未保存的文档GNOME会弹窗问“是否保存”这一弹就卡住了关机流程。这种情况下建议在关机命令前加上跳过交互的参数。不过说实话桌面环境下的定时关机本来就不适合强制断电它会留下未保存文件。所以如果你想在桌面机上做这个功能我建议先把提醒机制做好让人有保存时间。5.3 定时任务有时候执行有时候不执行如果你发现“今天关了、明天没关”那大概率是系统更新或者定时任务冲突导致的。比如Ubuntu的自动更新程序在23:00前后锁住了关机流程或者系统正在执行其他apt任务shutdown命令被排队阻塞。排查方法还是看日志。用journalctl查看关机时的系统日志看有没有异常阻塞。另外检查一下是不是存在多个定时任务互相冲突比如你既在root的crontab里写了关机又在系统timer里注册了一个关机两个都执行行为就会混乱。如果你两套方案都配置了建议只保留一套不然到时候自己都分不清是谁关的。5.4 用户权限问题提示Need to be root怎么办这是新手最常撞上的报错。在某天23:00的日志里你会看到类似shutdown: Need to be root原因很简单cron任务以普通用户的身份执行而shutdown命令需要root权限。解决办法是先切到root用户编辑定时任务sudo crontab -e关键点不要在自己用户的crontab里写关机命令必须用sudo crontab -e写到root的crontab里。5.5 定时任务被系统休眠“吞掉”的细节很多人遇到“到了23:00系统直接休眠了没有关机”的怪现象。这其实可能是power management和定时关机的交互问题。有些桌面环境默认在闲置一段时间后进入休眠休眠状态和关机状态不一样休眠后系统状态还在内存里但定时任务不会执行。如果你机器每天23点之前就自动休眠了那定时关机自然“没有发生”。处理方式要么禁用自动休眠要么把定时关机时间提前到休眠之前。如果你真的既想节能又想保留定时任务可以考虑“休眠定时唤醒”的组合但那需要更复杂的配置已经不属于本文讨论范围。5.6 我自己的实操习惯最后分享几个实际操作中的经验。第一我会先把定时测试时间设在2分钟后跑通了再改回23:00。别看这个步骤简单它能帮你把“配置问题”和“环境问题”快速分离开。第二我建议在cron方案跑通的情况下尽快迁移到systemd timer。原因很直接systemd的日志查询太方便了什么时候执行、有没有失败、为什么失败一条journalctl全能看到。对于需要长期维护的机器来说这个优势值得投入一点学习成本。第三我会定期检查系统日志确认定时关机没有因为某个版本更新而失效。Ubuntu系统升级时偶尔会动到systemd相关配置导致自定义timer单元被禁用。每次大版本更新后跑一下systemctl list-timers看看状态能省去后面不少排查时间。从“一开始随便跑一下crontab”到“后来用systemd timer管理所有周期任务”我自己也是这么一路过来的。定时关机看起来是个微不足道的小功能但它涉及的权限、时区、日志、电源管理这些知识点几乎把所有Linux基础概念都串起来了。把这个小功能吃透你以后再做任何定时任务都能少踩一半的坑。
延伸阅读

更多相关文章

2026/10/22 4:57:42

Docker 图形化管理实战:Ubuntu 16.04 部署 Portainer 全指南

先说一个我自己真实遇到的场景:服务器上跑了二十几个容器,每次排查问题,最烦的不是容器跑挂,而是想确认某台机器上到底哪个容器占着端口、哪个容器日志刷得飞快,还得先 ssh 上去敲一串docker ps、docker logs、docker …

2026/10/22 4:57:42

Linux下用官方.sh脚本快速安装CMake 3.27.6,绕开源码编译

简介:在Linux环境下搭建C编译工具链,CMake的安装常因系统自带版本过旧、与项目要求不匹配或路径配置繁琐而耗费额外精力。这款官方3.27.6 x86_64版安装脚本面向开发者和运维人员,兼容Ubuntu、CentOS等主流发行版,可在系统自带版本…

2026/10/22 4:57:42

Linux安装CMake 3.27.6:脚本安装与PATH配置避坑指南

简介:面向 Linux 下 C 开发与运维场景的 CMake 3.27.6 安装脚本资源,解决官方源码包需要手动配置编译、耗时且易出错的问题,适合需要固定版本构建工具、或在内网及自动化环境中批量部署的开发者与运维人员。压缩包采用 7z 格式,仅…

2026/10/22 5:52:45

光伏短期功率预测:多云天气误差突增的根因与工程解法

简介:本资源聚焦光伏电站短期发电功率预测这一关键工程问题,面向新能源电力系统研究人员、智能算法开发者及高校相关专业师生,提供一套融合LSTM与SVR的混合建模完整实现方案。资源包共78个文件,涵盖6个Python核心脚本(…

2026/10/22 5:52:45

Qt5.14.2 MinGW静态编译版部署与避坑指南

简介:本资源是基于Qt 5.14.2源码静态编译完成的MinGW 7.3.0 32位开发套件,专为Qt桌面端C开发者设计,尤其适用于需生成无依赖可执行文件、规避动态链接库部署问题的嵌入式调试、离线分发或教学演示场景。压缩包为RAR格式,体积达865…

2026/10/22 5:52:45

MySQL常用函数实战笔记:字符串、日期、窗口与SQL性能优化

做后端开发这些年,我发现自己每天写SQL时翻来覆去用到的,其实就那几十个函数。MySQL常见函数这个问题,隔三差五就有同事或者群里的人问起——有人问截取字符串怎么老是多一位,有人问两个日期相差几天为什么算出来是负的&#xff0…

2026/10/22 5:52:45

GitHub趋势榜第40周观察:AI降温,本地优先与极简依赖成主流

写这期周报的时候,正好是2026年第40周结束。这周GitHub趋势榜给我的感觉是:AI还在继续刷屏,但已经不再是单纯的大模型聊天应用,而是朝着更具体、更工程化的方向走。榜单上出现了不少本地优先的工具、极简依赖的基础库,…

2026/10/22 5:52:45

MySQL整数类型选型指南:从TINYINT到BIGINT的存储与实战

我在做后端开发的时候,最常被新人问倒的问题之一就是:建表的时候,用户ID到底用 INT 还是 BIGINT?一个状态字段用 TINYINT 会不会不够?明明都是整数,MySQL 为什么要分 TINYINT、INT、BIGINT 这么多种类&…

2026/10/22 5:47:45

大模型时代,如何用“以用带学”补回大二没听懂的数理基础课?

最近在几个技术社区里看到不少很有意思的帖子:有人翻出当年的《线性代数》教材,说“当年矩阵相乘都觉得要命,现在看大模型的注意力机制全是在玩矩阵”;也有人把《概率论》的课件重新找出来,说“终于搞懂老师当年为什么…

2026/10/21 4:53:08

金融AI落地指南:从调研报告到技术选型与工程实践

简介:这份PDF报告聚焦2025年金融服务业中国AI现状与趋势,面向金融科技从业者、AI战略规划人员及关注行业数字化转型的研究者,帮助读者把握生成式AI在银行、支付、交易等场景中的落地路径与投资方向。资源包内含1个PDF文件,大小约1…

2026/10/22 0:01:49

电商智能运营体系从0到1:架构设计、落地步骤与避坑指南

前两年我们团队接了一个电商平台的运营中台项目,目标很直白:把过去靠运营拍脑袋做的选品、定价、发券、推活动这些事,逐步用数据算法和自动化流程代替。项目名字内部就叫“电商智能运营体系”。最近有不少朋友问我当时是怎么设计的、踩过哪些…

2026/10/22 0:01:49

若依框架AI代码生成不稳定?用Agent Skill三层结构+五步法搞定

最近一段时间,我一直想把后台管理系统里那些机械重复的增删改查代码交给AI去写。框架用的是若依,按理说这类业务代码模式非常固定,应该是AI最擅长的事情。可真试下来却不是那么回事——你让AI生成一个用户管理模块,它给出的Contro…

还想了解更多?直接咨询顾问

免费诊断 + 免费方案 + 透明报价。

全国咨询热线400-8866-253
免费获取方案
☎咨询二维码 ☎ ↑