实际生产环境中某些情况下 Linux 服务器系统在出现致命错误需要远程进行重启,通过常规的 reboot、init 6 等方法无法正常重启(例如重启时卡在驱动程序里等情况),这时就需要通过下面介绍的几种特殊的方法进行强制重启。
注意
下面这些强制重启 Linux 的方法都是直接跳过 umount 文件系统及 sync 等 *** 作,可能导致数据损坏,不在特殊情况下请勿使用。
另外当然这些都是需要 root 超级用户权限的哦。
reboot 命令
直接通过运行 reboot -nf 命令,这样重启时可以指定跳过 init 的处理和 sync *** 作,这样可以避免大多数情况下的问题。
magic SysRq key 方法
magic SysRq key 通过 proc 接口提供用户直接发底层命令给 kernel 的功能,可以实现关机、重启、宕机等 *** 作
Linux kernel 需要开启 CONFIG_MAGIC_SYSRQ 才可以支持 magic SysRq key。
运行下面两条命令就可以直接强制重启系统:
[root@localhost ~]# echo 1 >/proc/sys/kernel/sysrq
[root@localhost ~]# echo b >/proc/sysrq-trigger
相应的直接强制关机的命令:
[root@localhost ~]# echo 1 >/proc/sys/kernel/sysrq
[root@localhost ~]# echo o >/proc/sysrq-trigger
watchdog 方法
如果 Linux kernel 未开启 magic SysRq key 或者不起作用,可以尝试使用 watchdog 重启方法。watchdog 通过监控数据输入是否正常可以实现在系统出现异常时自动重启系统,这里我们刚好可以借用的。
首先需要加载 watchdog 支持,这个和主板硬件设备有关,如果只需要软件模拟的,可以运行:
[root@localhost ~]# modprobe softdog
命令加载软件 watchdog 支持,接着再运行:
[root@localhost ~]# cat /dev/watchdog
命令,该命令会马上退出并报错,同时系统日志中就会提示:
softdog: Unexpected close, not stopping watchdog!
这就表示 watchdog 设备是被意外关闭的而不是正常停止的,大约等待 60 秒之后你就会发现 Linux 系统自动重启了。
Linux watchdog 的异常等待时间是通过 /proc/sys/kernel/watchdog_thresh 设置的,一般默认为 60 秒。
IPMI 方法
上面几种方法都不能用?如果你的主板刚好支持 IPMI 管理接口的话
那可以直接通过 IPMI 实现硬件上的强制关机或重启。
首先加载 IPMI 支持:
[root@localhost ~]# modprobe ipmi_msghandler ipmi_devintf ipmi_si
确认 IPMI 设备是否已找到:
[root@localhost ~]# ls -l /dev/ipmi*
如果输出正常的话表示 IPMI 被正确加载了,接着安装 ipmitool 管理工具。
ipmitool 可以通过 IPMI 接口完成对本机或远程主机的一系列管理 *** 作。
这里我们就用直接电源管理的,重启系统:
[root@localhost ~]# ipmitool power reset
运行完成后主机就会马上重启,相应的关闭主机可以运行命令:
[root@localhost ~]# ipmitool power off
ipmitool 还可以实现在系统未启动时远程查看监控主板硬件状态等功能
解决方法,root密码 执行 fdisk -l查看磁盘(Repair filesystem)# fdisk -l 根据看到的磁盘依次修复 ,例如:
(Repair filesystem)#fsck -y /dev/sda1
(Repair filesystem)#fsck -y /dev/sda2
(Repair filesystem)#fsck -y /dev/sda3
(Repair filesystem)#fsck -y /dev/sda4
HOHO相当有难度的问题。首先,我想知道的是如何叫意外杀死,一切没有执行完的都算是意外杀死么?我看用shell解决是比较合适的。大致流程如下:
首先我希望你有1234的源代码,因为我不知道你所谓的意外杀死是什么情况下意外杀死,比如通过kill来发送信号杀死他。请注意,如果你程序执行出现异常也是通过信号来杀死,不过是内核发送的,而不是你自己来发送的。所以我希望你修改1234的源代码,在他正常结束的情况下,你最好有个输出标志标识他正常结束。比如你的程序是C写的,那么希望你在正常结束后调用一个printf("success end")这个应该不难。
紧接着,你写一个shell脚本,这个脚本应该是这样
绝对路径/1234 >绝对路径/my.txt,以后想启动这个进程就用这个脚本来启动。
在希望你写一个脚本,这个脚本执行ps -le首先查看进程里面是否还存在1234这个进程,如果有就什么都不做退出,如果没有了,那你就检查my.txt文件看是否是正常结束了,如果正常结束就从cron守护进程的配置文件移除我这个检测脚本。如果没有找到 success end的话,那么就再次启动。
最后将这个脚本加到cron守护进程的配置文件中,定时启动它检测。
有点麻烦,不过这是我能想到的办法了,也许其它人有更好的办法。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)