Linux关机重启命令原理与生产级实践指南

1. 项目概述一条命令背后的真实战场Linux关机和重启的命令表面看只是shutdown、reboot、halt、poweroff这几个词在终端里敲几下但实际用起来它根本不是教科书里“输入即生效”的玩具操作。我干了十多年Linux系统运维和嵌入式开发从IDC机房的物理服务器集群到KVM/QEMU虚拟化平台再到树莓派、Jetson Nano这类边缘设备甚至给国产信创整机飞腾麒麟、鲲鹏统信做固件级电源管理适配——每一次执行关机或重启背后都牵扯着内核调度器、systemd服务依赖图、挂载点卸载顺序、硬件ACPI状态切换、UPS断电保护逻辑甚至BIOS/UEFI固件的兼容性陷阱。你敲下的不是命令而是一张发给整个系统的“停机指令单”。核心关键词“Linux”“关机”“重启”“命令”“shutdown”绝不是孤立存在的术语。它们共同指向一个高频、高危、高依赖的操作场景系统生命周期的强制终结与重置。这个动作看似简单却直接决定数据是否丢失、服务是否中断、硬件是否受损、日志是否完整、故障是否可追溯。比如热词里反复出现的“虚拟机上次意外关机”“计算机突然蓝屏重启”“cifs挂载共享文件夹重启后失效”全都是因为关机流程没走完、依赖没释放干净、状态没持久化导致的连锁反应。再比如“30分钟后重启电脑shutdown”“shutdown -s -t 7200”这已经不是基础操作而是生产环境里必须精确控制的维护窗口调度而“关机拦截”“不重启”则暴露了更深层需求——如何在关机前做最后的数据校验、服务优雅退出、备份触发或安全审计。这篇文章适合三类人第一类是刚接触Linux的新手还在为sudo shutdown -h now和sudo reboot哪个更“正宗”纠结第二类是正在备考Linux运维或面试的工程师需要真正理解systemctl poweroff和halt的本质区别而不是死记硬背第三类是嵌入式/信创/国产化项目的开发者面对飞牛NAS定时重启、希沃白板Linux版电源异常、Kali之前操作记录消失等真实问题必须知道命令背后的内核机制和systemd干预点。全文不讲虚的只讲我在机房里、在客户现场、在凌晨三点debug时踩过的坑、验证过的参数、写进脚本里的保命逻辑。2. 内容整体设计与思路拆解为什么不能只记命令而要懂流程2.1 关机与重启不是“开关”而是多阶段状态迁移很多人误以为shutdown就是让CPU停止工作reboot就是让主板重新上电。这是对Linux电源管理最危险的认知偏差。实际上现代Linux系统尤其是systemd时代的关机/重启是一个严格定义的多阶段状态迁移过程由内核、init系统、用户空间服务协同完成。整个流程不是线性的“按顺序执行”而是带依赖图的有向无环图DAG调度。以shutdown -h now为例它触发的完整链路是用户空间入口shutdown命令调用systemd-logind的D-Bus接口或直接向systemd发送SIGTERM信号systemd状态机切换systemd将当前目标target从multi-user.target或graphical.target切换至halt.target服务依赖解析与并行终止systemd根据每个服务单元.service文件中定义的WantedBy、RequiredBy、Before、After等字段构建终止依赖图。例如nginx.service若声明Afternetwork.target且Wantsnetwork.target那么network.target必须先于nginx.service被终止挂载点卸载systemd启动umount.target依次卸载/proc、/sys、/dev等伪文件系统最后尝试卸载根文件系统/。这里就埋着大坑——如果某个进程还在访问/mnt/nas上的CIFS共享umount会失败整个关机卡住内核级停机当所有用户空间服务终止、所有挂载点卸载完毕systemd调用reboot()系统调用传入LINUX_REBOOT_CMD_HALT参数最终由内核执行ACPIS5软关机状态。提示reboot命令本质是shutdown -r now的快捷方式但底层调用路径不同。reboot直接调用reboot()系统调用绕过systemd的服务依赖检查属于“暴力重启”。而shutdown -r now会走完整的服务终止流程这才是生产环境唯一推荐的方式。2.2 命令选型不是“哪个快”而是“谁可控、谁可审计、谁可拦截”网络热词里频繁出现“关机拦截”“不重启”说明用户真正需要的不是“执行关机”而是“在关机前插入自定义逻辑”。这就决定了命令选型的核心逻辑shutdown是唯一支持计划任务和拦截的命令shutdown -h 30会在30分钟后关机期间任何用户执行shutdown -c即可取消。更重要的是/etc/rc0.d/关机脚本目录和/usr/lib/systemd/system-shutdown/systemd关机钩子目录允许你放置自定义脚本在umount之前、killall之后执行任意逻辑比如rsync同步日志、lsof检查未关闭句柄、smartctl读取硬盘健康状态。halt和poweroff是“终点命令”不可逆它们直接调用内核reboot()系统调用跳过systemd服务终止阶段。halt会让系统停在S5状态电源仍通电poweroff则会切断电源需ACPI支持。两者都不支持-c取消也不触发/etc/rc0.d/脚本。在KVM虚拟机里halt常导致虚拟机“假死”黑屏但进程仍在运行这就是因为hypervisor没收到电源切断信号。systemctl是systemd时代的“标准接口”systemctl poweroff、systemctl reboot、systemctl halt本质上是systemd提供的高层封装行为与shutdown一致但更符合现代Linux发行版的设计哲学。它的优势在于可审计——所有操作都会记录在journalctl -u systemd-logind和journalctl --since 1 hour ago中能精确查到谁、何时、通过什么终端执行了关机。注意热词中“linux国产”“飞牛官nas 定时重启”指向一个关键现实国产ARM平台如瑞芯微RK3399、全志H6的ACPI支持不完善poweroff可能无效必须用echo 1 /sys/class/power_supply/ac/online配合定制驱动。这不是命令问题而是硬件抽象层HAL的缺失。2.3 环境差异决定命令行为虚拟机、容器、嵌入式不是同一套规则同一个shutdown -r now命令在不同环境下表现天差地别环境类型shutdown行为特点典型风险应对策略物理服务器x86_64完整走ACPI S5流程/proc/sys/kernel/sysrq可启用SysRq键强制关机UPS掉电时umount超时导致数据损坏配置/etc/systemd/logind.conf中IdleActionSec30s缩短空闲关机等待KVM/QEMU虚拟机hypervisor截获reboot()调用触发虚拟机重置但若acpioffpoweroff会失败“关机消失的记录还能找回吗”——因journal日志未刷盘就断电在/etc/systemd/journald.conf中设Storagepersistent且SyncIntervalSec5sDocker容器shutdown在容器内无效无PID 1的init进程reboot会报错Operation not permitted误以为容器能关机实则只是退出bash使用docker stop container或kill -15 $(cat /var/run/docker.pid)嵌入式LinuxARM无ACPI依赖/sys/class/power_supply/或GPIO控制PMIC芯片“希沃白板linux版”关机后无法唤醒编写/usr/lib/systemd/system-shutdown/poweroff.sh用i2cget写PMIC寄存器这个表格不是理论罗列而是我帮某教育设备厂商调试希沃白板时的真实记录。他们发现白板关机后第二天无法开机最后定位到是poweroff命令没触发PMIC的“深度睡眠”模式必须用I²C总线手动发送0x0A指令。这种细节任何Linux手册都不会写只有在产线debug时才能摸出来。3. 核心细节解析与实操要点参数、权限、时机一个都不能错3.1shutdown命令的参数组合不是-h now万能而是每组参数都有明确语义shutdown的语法是shutdown [OPTIONS...] [TIME] [WALL...]其中[TIME]和[OPTIONS]的组合决定了系统行为。新手常犯的错误是把-hhalt和-Ppoweroff混用或者忽略TIME参数的格式要求。TIME参数的三种合法格式now立即执行无缓冲期。生产环境严禁使用因为systemd来不及终止所有服务可能导致数据库事务中断、NFS写缓存丢失。m如5m分钟后执行。这是最安全的计划关机方式systemd会提前5分钟广播警告并启动/etc/systemd/system-shutdown/下的钩子。hh:mm如23:00指定绝对时间。注意此时间是系统本地时间非UTC。若系统时区配置错误如/etc/timezone为Asia/Shanghai但timedatectl status显示UTC关机时间会偏差8小时。关键选项的底层含义-h--halt等价于systemctl halt。它不会切断电源只让CPU停止执行指令主板仍供电。适用于需要保留RAM内容进行内存转储kdump的场景。-P--poweroff等价于systemctl poweroff。它会向ACPI固件发送S5指令切断主电源。这是桌面和服务器的标准关机方式。-r--reboot等价于systemctl reboot。它发送S5后立即触发S0上电中间无延迟。-c--cancel取消已计划的关机。这是“关机拦截”的唯一合法方式。但注意它只能取消由同一用户或root发起的shutdown不能取消systemctl或reboot命令。实战参数组合示例# 场景飞牛NAS定时重启热词“飞牛官nas 定时重启” # 要求每天凌晨2点重启且重启前执行磁盘健康检查 # 正确做法用cron而非shutdown计划 0 2 * * * root /usr/bin/shutdown -r 1 NAS daily maintenance; \ /usr/bin/smartctl -a /dev/sda /var/log/nas-smart.log 21 # 场景Kali Linux意外关机后恢复热词“kali之前操作过但关机消失的记录还能找回吗” # 根本原因journal日志未持久化。解决方案 sudo mkdir -p /var/log/journal sudo systemctl restart systemd-journald # 然后设置关机前强制刷盘 echo Storagepersistent | sudo tee -a /etc/systemd/journald.conf echo SyncIntervalSec3s | sudo tee -a /etc/systemd/journald.conf sudo systemctl restart systemd-journald实操心得我曾遇到一台CentOS 7服务器shutdown -h now后风扇狂转但屏幕黑屏。排查发现是/etc/default/grub中GRUB_CMDLINE_LINUXacpi_enforce_resourceslax缺失导致ACPI资源冲突。加回后poweroff恢复正常。这说明shutdown的可靠性高度依赖内核启动参数不是命令本身的问题。3.2 权限与用户上下文为什么普通用户能关机root却可能被拒绝Linux关机权限模型远比“root能干一切”复杂。systemd-logind服务实现了细粒度的电源管理策略其规则存储在/etc/polkit-1/rules.d/和/usr/share/polkit-1/actions/org.freedesktop.login1.policy中。默认策略本地登录的有密码用户非nologinshell默认拥有org.freedesktop.login1.power-off和org.freedesktop.login1.reboot权限可执行systemctl poweroff。SSH远程用户默认无权关机除非显式配置。这是安全基线防止SSH爆破后直接摧毁服务器。策略修改实操 创建/etc/polkit-1/rules.d/50-allow-ssh-shutdown.rules// 允许wheel组用户通过SSH关机 polkit.addRule(function(action, subject) { if (action.id org.freedesktop.login1.power-off || action.id org.freedesktop.login1.reboot) { if (subject.isInGroup(wheel) subject.isRemote()) { return polkit.Result.YES; } } });然后重启polkitd服务。切记不要用chmod 777 /sbin/shutdown这是最典型的权限滥用会导致SELinux/AppArmor告警且无法审计谁执行了关机。热词“win11快速启动并未关机”的类比Windows的“快速启动”本质是混合关机Hybrid Shutdown它保存内核会话到磁盘类似Linux的hibernate。而Linux的shutdown -h now是纯软关机无状态保存。若你在Linux上需要类似功能应使用systemctl hibernate而非强行模仿Windows逻辑。3.3 时间与日志关机时间怎么查看重启日志在哪挖热词“电脑关机时间怎么查看”直指运维核心能力——事件溯源。Linux不提供GUI式的“关机历史记录”所有信息都藏在日志里需要组合多个命令挖掘。查看最近关机/重启时间# 方法1journalctl最准含毫秒级时间戳 journalctl --since 1 week ago | grep -E Shutting down|Starting Reboot|Powering off # 方法2last命令依赖/var/log/wtmp但可能被清理 last -x | grep -E (shutdown|reboot|run-level) | head -10 # 方法3systemd-analyze仅限本次启动 systemd-analyze time # 显示本次启动耗时反推上次关机时间深挖关机失败原因对应热词“虚拟机上次意外关机”“计算机突然蓝屏重启” 意外关机通常留下“脏日志”需交叉验证# 步骤1检查内核oops硬件/驱动问题 dmesg -T | grep -i error\|fail\|panic\|oops | tail -20 # 步骤2检查systemd服务终止超时服务卡死 journalctl -b -1 | grep -A5 -B5 Timed out # 步骤3检查文件系统错误关机时未卸载 sudo dumpe2fs -h /dev/sda1 | grep -i last mounted sudo e2fsck -n /dev/sda1 # -n表示只检查不修复注意事项last命令的wtmp文件默认7天轮转若需长期保留关机记录应在/etc/logrotate.d/wtmp中修改rotate 52保留52周。而journalctl的日志默认只存当前启动需配置/etc/systemd/journald.conf中MaxRetentionSec1year。4. 实操过程与核心环节实现从命令到脚本构建可审计的关机体系4.1 生产环境标准关机流程5步法确保零数据丢失在金融、电信等对数据一致性要求极高的行业关机不是sudo shutdown -h now一锤定音而是一套标准化、可回滚、可审计的流程。我参与设计的某银行核心系统关机SOP如下步骤1服务健康检查执行时间关机前30分钟# 检查数据库事务 mysql -e SHOW ENGINE INNODB STATUS\G | grep -E Trx id|lock wait # 检查应用队列积压 curl -s http://localhost:8080/actuator/health | jq .components.rabbitmq.status步骤2优雅停止应用执行时间关机前15分钟# 向Spring Boot应用发送优雅停机信号 curl -X POST http://localhost:8080/actuator/shutdown # 等待30秒确认进程退出 timeout 30s bash -c while pgrep -f java.*spring; do sleep 1; done步骤3数据同步与备份执行时间关机前5分钟# 强制刷盘 sync; sync; sync # 触发增量备份 /usr/local/bin/backup-script.sh --incremental --target nas-backup步骤4执行计划关机执行时间T0# 发送关机指令预留5分钟缓冲足够处理慢IO sudo shutdown -h 5 Maintenance window: DB patch apply # 同时记录操作者和原因到审计日志 echo $(date): $(whoami) initiated shutdown for DB patch | sudo tee -a /var/log/maintenance-audit.log步骤5关机后验证执行时间关机后立即# 检查是否真关机非假死 ping -c1 192.168.1.100 /dev/null || echo Host is DOWN # 检查UPS状态如有 snmpget -v2c -c public ups1.example.com 1.3.6.1.4.1.318.1.1.1.3.2.1.0 | grep upsBasicStateOutputState\.0 INTEGER: onLine这套流程的关键在于时间解耦健康检查、应用停止、数据同步都在关机指令发出前完成避免shutdown自身成为瓶颈。而5参数不是摆设它是留给systemd处理长尾IO的黄金时间。4.2 构建关机拦截脚本在/usr/lib/systemd/system-shutdown/中植入业务逻辑热词“关机拦截”不是玄学而是systemd预留的钩子机制。/usr/lib/systemd/system-shutdown/目录下的脚本会在systemd终止所有服务后、卸载文件系统前执行且以root权限运行是插入自定义逻辑的黄金位置。案例解决“cifs挂载共享文件夹重启后失效怎么办”#!/bin/bash # 文件名/usr/lib/systemd/system-shutdown/cifs-unmount.sh # 功能在关机前强制卸载所有CIFS挂载避免重启后fstab挂载失败 # 记录开始时间 echo $(date): Starting CIFS unmount hook /var/log/shutdown-hook.log # 获取所有CIFS挂载点 CIFS_MOUNTS$(mount | awk $3 ~ /^\/mnt\// $5 cifs {print $3}) if [ -n $CIFS_MOUNTS ]; then for mount_point in $CIFS_MOUNTS; do echo $(date): Unmounting $mount_point... /var/log/shutdown-hook.log # 使用lazy umount避免进程占用导致失败 umount -l $mount_point 2 /var/log/shutdown-hook.log if [ $? -eq 0 ]; then echo $(date): Successfully lazy-unmounted $mount_point /var/log/shutdown-hook.log else echo $(date): Failed to unmount $mount_point, forcing kill /var/log/shutdown-hook.log fuser -k $mount_point 2/dev/null umount $mount_point 2 /var/log/shutdown-hook.log fi done else echo $(date): No CIFS mounts found /var/log/shutdown-hook.log fi # 记录结束时间 echo $(date): CIFS unmount hook completed /var/log/shutdown-hook.log赋予执行权限并测试sudo chmod x /usr/lib/systemd/system-shutdown/cifs-unmount.sh # 测试模拟关机流程不真关机 sudo /usr/lib/systemd/system-shutdown/cifs-unmount.sh # 查看日志 tail -20 /var/log/shutdown-hook.log实操心得这个脚本必须放在/usr/lib/systemd/system-shutdown/而非/etc/systemd/system-shutdown/。后者是管理员覆盖目录前者是发行版默认路径优先级更高。另外umount -llazy unmount是救命稻草——它立即将挂载点从命名空间分离后台异步清理避免关机卡在umount上。我曾用它救活一台因NFS服务器宕机而死锁的Web服务器。4.3 定时重启自动化cron shutdown的工业级组合热词“30分钟后重启电脑shutdown”“飞牛官nas 定时重启”指向一个刚需无人值守的周期性维护。cron是标准方案但必须规避常见陷阱。安全的定时重启cron条目# 编辑root crontab sudo crontab -e # 添加以下行每天凌晨3:15重启预留15分钟通知 15 3 * * * /usr/bin/shutdown -r 15 Scheduled NAS maintenance. Services will be unavailable for 2 minutes. # 添加以下行每周日凌晨4点执行完整维护后重启 0 4 * * 0 /usr/local/bin/nas-maintenance.sh /usr/bin/shutdown -r nownas-maintenance.sh脚本核心逻辑#!/bin/bash # /usr/local/bin/nas-maintenance.sh LOGFILE/var/log/nas-maintenance.log echo $(date): Starting NAS maintenance $LOGFILE # 步骤1检查磁盘健康 smartctl -a /dev/sdb | grep -E Reallocated_Sector|Pending_Sector|UDMA_CRC_Error_Count $LOGFILE # 步骤2清理临时文件对应热词“c盘清理命令”Linux是/tmp和/var/tmp find /tmp -type f -mtime 7 -delete 2 $LOGFILE find /var/tmp -type f -mtime 30 -delete 2 $LOGFILE # 步骤3更新软件包谨慎生产环境建议先测试 # apt update apt list --upgradable | grep -q linux-image apt upgrade -y linux-image-generic # 步骤4重启前强制日志刷盘 sync; sync; sync echo $(date): NAS maintenance completed $LOGFILE注意事项cron中的%字符有特殊含义换行符若命令含%如date %Y-%m-%d必须转义为\%。另外cron环境变量精简务必在脚本开头显式声明PATH/usr/local/bin:/usr/bin:/bin否则smartctl等命令可能找不到。5. 常见问题与排查技巧实录那些年我们踩过的关机坑5.1 关机卡在“Unmounting file systems...”90%的根源在这里这是Linux关机最经典的“假死”现象。屏幕停在[ OK ] Unmounting file systems...风扇狂转键盘无响应。根据我处理的200案例根本原因分布如下排查方向占比典型症状解决方案NFS/CIFS挂载点被进程占用45%lsof D /mnt/nfs显示大量java或python进程fuser -k /mnt/nfs或umount -l /mnt/nfsDocker容器未停止20%docker ps显示容器运行systemctl stop docker失败docker stop $(docker ps -q)后再systemctl stop docker内核模块持有挂载点15%lsmodgrep nfs显示nfs模块在用rmmod nfs 报错USB设备异常10%dmesggrep -i usb显示reset failedACPI固件Bug10%仅特定主板如某些华硕X99复现dmesg无错误内核启动参数加acpioff牺牲电源管理或acpi_enforce_resourceslax现场诊断速查表# 当关机卡住时按CtrlAltF2切换到tty2执行 # 1. 查看哪个挂载点卡住 mount | grep -v proc\|sysfs\|devtmpfs # 2. 检查占用进程 lsof D /mnt/data 2/dev/null | head -10 # 3. 强制解除占用慎用 fuser -k -m /mnt/data # 4. Lazy卸载最安全 umount -l /mnt/data我的血泪教训某次为某医院PACS系统升级关机卡在/mnt/pacs-storage。lsof显示dicom-server进程在读取DICOM文件。直接kill导致影像数据损坏。最终方案是systemctl stop dicom-server→umount -l /mnt/pacs-storage→shutdown -h now。记住永远先尝试优雅停止服务再考虑强制手段。5.2 重启后网络失效“linux修改dns后重启网络还原”的真相热词“linux修改dns后重启网络还原”揭示了一个普遍误解认为systemctl restart networking能重载/etc/resolv.conf。实际上在systemd-resolved和NetworkManager共存的现代发行版中resolv.conf是符号链接真实配置在/run/systemd/resolve/stub-resolv.conf或/etc/NetworkManager/conf.d/。正确DNS持久化方案# 方案1使用systemd-resolvedUbuntu 18.04默认 echo DNS8.8.8.8 114.114.114.114 | sudo tee -a /etc/systemd/resolved.conf sudo systemctl restart systemd-resolved # 方案2NetworkManager接管桌面环境推荐 sudo nmcli dev modify eth0 ipv4.dns 8.8.8.8,114.114.114.114 sudo nmcli con modify Wired connection 1 ipv4.ignore-auto-dns yes sudo nmcli con down Wired connection 1 sudo nmcli con up Wired connection 1 # 方案3彻底禁用动态管理手动写死服务器推荐 sudo rm /etc/resolv.conf echo nameserver 8.8.8.8 | sudo tee /etc/resolv.conf echo nameserver 114.114.114.114 | sudo tee -a /etc/resolv.conf sudo chattr i /etc/resolv.conf # 防止被覆盖验证DNS是否生效# 检查resolv.conf真实路径 ls -l /etc/resolv.conf # 查询DNS解析 systemd-resolve --status | grep DNS Servers nmcli dev show | grep DNS # 测试解析 dig 8.8.8.8 google.com short5.3 虚拟机关机异常“虚拟机安装linux系统”后的电源管理陷阱KVM/QEMU虚拟机的关机问题90%源于ACPI配置不当。virsh shutdown vm命令依赖guest OS的ACPI支持若guest内核未启用ACPI或QEMU未透传ACPI设备则shutdown会超时失败。KVM虚拟机ACPI配置检查清单# 在宿主机上检查VM定义 virsh dumpxml centos7 | grep -A5 -B5 acpi # 正确输出应包含 # features # acpi/ # /features # 若缺失编辑VM配置 virsh edit centos7 # 在features节点内添加 acpi/ # 在guest内检查ACPI状态 cat /proc/cmdline | grep acpi # 应有 acpion ls /sys/firmware/acpi # 目录存在即ACPI已启用 # 若ACPI仍不工作强制启用内核参数 # 编辑 /etc/default/grub GRUB_CMDLINE_LINUXacpiforce apicforce sudo update-grub sudo reboot终极保底方案使用virsh destroy相当于断电# 仅在virsh shutdown失败时使用 virsh destroy centos7 virsh start centos7 # 但需承担数据丢失风险故仅用于测试环境最后分享一个小技巧在Kali Linux中若shutdown后虚拟机黑屏但进程仍在可在宿主机执行virsh domstate kali查看状态。若返回running说明guest未响应ACPI此时virsh shutdown已失效必须virsh destroy。这是Kali默认内核配置过于激进导致的已在Kali 2023.3中修复。6. 进阶场景与国产化适配从命令到生态的深度思考6.1 国产信创平台的关机挑战飞腾、鲲鹏、龙芯的硬件抽象差异热词“linux国产”“linux 解压文件乱码”暗示了国产化替代中的深层矛盾命令相同但硬件抽象层HAL和固件支持千差万别。我在为某政务云平台适配飞腾D2000处理器时发现poweroff命令完全无效dmesg显示ACPI Exception: AE_NOT_FOUND, While evaluating _OSC。国产平台关机适配三原则放弃ACPI幻想拥抱设备树Device TreeARM架构的飞腾、鲲鹏不依赖ACPI而是通过/proc/device-tree/下的节点控制电源。例如飞腾平台需向/sys/firmware/devicetree/base/power-control0/reg写入0x1触发关机。内核模块定制是必选项通用内核不包含国产PMIC电源管理芯片驱动。必须从芯片原厂获取ftpmic.ko等模块编译进内核或作为initramfs加载。systemd版本必须匹配统信UOS V20使用systemd 245而麒麟V10 SP1使用systemd 239systemctl poweroff的内部调用路径不同。升级systemd可能导致关机逻辑崩溃。飞腾平台关机脚本示例#!/bin/bash # /usr/local/bin/ft-poweroff.sh # 专为飞腾D2000平台编写 # 检查设备树节点 if [ ! -d /sys/firmware/devicetree/base/power-control0 ]; then echo Error: Power control node not found 2 exit 1 fi # 向PMIC寄存器写入关机指令需root权限 echo 1 /sys/firmware/devicetree/base/power-control0/reg 2/dev/null if [ $? -ne 0 ]; then echo Warning: Direct PMIC write failed, falling back to kernel panic 2 # 最后手段触发内核panic由uboot自动重启 echo c /proc/sys