linux可以用root重启吗_系统运维

系统的几种方法

实际生产环境中某些情况下 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 还可以实现在系统未启动时远程查看监控主板硬件状态等功能

烽火机器宕机，重启后报错 kernel:NMI watchdog: BUG: soft lockup - CPU#23 stuck for 22s ，且无法进入系统

soft lockup是指内核中有BUG导致在内核模式下一直循环的时间超过67s（根据实现和配置有所不同），而其他进程得不到运行的机会

1 重启机器，在进入 *** 作系统菜单选择内核时，按e进入编辑模式

2 在quiet前加上 nomodeset xdriver=vesa brokenmodules=ast

3 按ctrl+x重新进入系统

修改 vim /etc/default/grub 将上面内容在同样的地方修改

然后执行 grub2-mkconfig -o /boot/grub2/grub.cfg

再执行 dracut -force

最后重启

启动后查看 cat /proc/cmdline

　在进行Linux系统 *** 作的时候，有时候会遇到一次用户态进程死循环，即系统反应迟钝、进程挂死等问题，那么遇到这些问题又该如何解决呢？下面小编就给大家介绍下一次用户态进程死循环的问题该如何处理。

Linux下如何处理一次用户态进程死循环问题

1、问题现象

业务进程（用户态多线程程序）挂死， *** 作系统反应迟钝，系统日志没有任何异常。从进程的内核态堆栈看，看似所有线程都卡在了内核态的如下堆栈流程中：

［root@vmc116 ~］# cat /proc/27007/task/11825/stack

［《ffffffff8100baf6》］ retint_careful+0x14/0x32

［《ffffffffffffffff》］ 0xffffffffffffffff

2、问题分析

1）内核堆栈分析

从内核堆栈看，所有进程都阻塞在 retint_careful上，这个是中断返回过程中的流程，代码（汇编）如下：

entry_64.S

代码如下：

ret_from_intr：

DISABLE_INTERRUPTS（CLBR_NONE）

TRACE_IRQS_OFF

decl PER_CPU_VAR（irq_count）

/* Restore saved previous stack */

popq %rsi

CFI_DEF_CFA rsi，SS+8-RBP /* reg/off reset after def_cfa_expr */

leaq ARGOFFSET-RBP（%rsi）， %rsp

CFI_DEF_CFA_REGISTER rsp

CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET

。。。

retint_careful：

CFI_RESTORE_STATE

bt $TIF_NEED_RESCHED，%edx

jnc retint_signal

TRACE_IRQS_ON

ENABLE_INTERRUPTS（CLBR_NONE）

pushq_cfi %rdi

SCHEDULE_USER

popq_cfi %rdi

GET_THREAD_INFO（%rcx）

DISABLE_INTERRUPTS（CLBR_NONE）

TRACE_IRQS_OFF

jmp retint_check

这其实是用户态进程在用户态被中断打断后，从中断返回的流程，结合retint_careful+0x14/0x32，进行反汇编，可以确认阻塞的点其实就在

SCHEDULE_USER

这其实就是调用schedule（）进行调度，也就是说当进程走到中断返回的流程中时，发现需要调度（设置了TIF_NEED_RESCHED），于是在这里发生了调度。

有一个疑问：为什么在堆栈中看不到schedule（）这一级的栈帧呢？

因为这里是汇编直接调用的，没有进行相关栈帧压栈和上下文保存 *** 作。

2）进行状态信息分析

从top命令结果看，相关线程实际一直处于R状态，CPU几乎完全耗尽，而且绝大部分都消耗在用户态：

［root@vmc116 ~］# top

top - 09:42:23 up 16 days， 2:21， 23 users， load average： 84.08， 84.30， 83.62

Tasks： 1037 total， 85 running， 952 sleeping， 0 stopped， 0 zombie

Cpu（s）： 97.6%us， 2.2%sy， 0.2%ni， 0.0%id， 0.0%wa， 0.0%hi， 0.0%si， 0.0%st

Mem： 32878852k total， 32315464k used， 563388k free， 374152k buffers

Swap： 35110904k total， 38644k used， 35072260k free， 28852536k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

27074 root 20 0 5316m 163m 14m R 10.2 0.5 321:06.17 z_itask_templat

27084 root 20 0 5316m 163m 14m R 10.2 0.5 296:23.37 z_itask_templat

27085 root 20 0 5316m 163m 14m R 10.2 0.5 337:57.26 z_itask_templat

27095 root 20 0 5316m 163m 14m R 10.2 0.5 327:31.93 z_itask_templat

27102 root 20 0 5316m 163m 14m R 10.2 0.5 306:49.44 z_itask_templat

27113 root 20 0 5316m 163m 14m R 10.2 0.5 310:47.41 z_itask_templat

25730 root 20 0 5316m 163m 14m R 10.2 0.5 283:03.37 z_itask_templat

30069 root 20 0 5316m 163m 14m R 10.2 0.5 283:49.67 z_itask_templat

13938 root 20 0 5316m 163m 14m R 10.2 0.5 261:24.46 z_itask_templat

16326 root 20 0 5316m 163m 14m R 10.2 0.5 150:24.53 z_itask_templat

6795 root 20 0 5316m 163m 14m R 10.2 0.5 100:26.77 z_itask_templat

27063 root 20 0 5316m 163m 14m R 9.9 0.5 337:18.77 z_itask_templat

27065 root 20 0 5316m 163m 14m R 9.9 0.5 314:24.17 z_itask_templat

27068 root 20 0 5316m 163m 14m R 9.9 0.5 336:32.78 z_itask_templat

27069 root 20 0 5316m 163m 14m R 9.9 0.5 338:55.08 z_itask_templat

27072 root 20 0 5316m 163m 14m R 9.9 0.5 306:46.08 z_itask_templat

27075 root 20 0 5316m 163m 14m R 9.9 0.5 316:49.51 z_itask_templat

。。。

3）进程调度信息

从相关线程的调度信息看：