linux宕机，linux关闭端口

大家好，今天小编来为大家解答linux宕机这个问题，linux关闭端口很多人还不知道，现在让我们一起来看看吧！

linux 宕机处理

按住 Alt-Print的时候就相当于按住了 Sys Rq键，这个时候输入的一切都会直接由 Linux内核来处理，它可以进行许多低级操作。这个方法可以在各种情况下安全地重启计算机，具体操作如下:

1、shutdown命令安全地将系统关机。在系统关机前使用shutdown命令﹐系统管理员会通知所有登录的用户系统将要关闭。并且login指令会被冻结，即新的用户不能再登录。

2、halt——最简单的关机命令，其实halt就是调用shutdown-h。halt执行时﹐杀死应用进程﹐执行sync系统调用﹐文件系统写操作完成后就会停止内核。

3、reboot的工作过程差不多跟halt一样，不过它是引发主机重启，而halt是关机。它的参数与halt相差不多。

4、init是所有进程的祖先，它的进程号始终为1， init 0为关机，init 1为重启。

如何查找Linux死机原因

因为 Linux广泛用于生产环境，所以每一次宕机都会引起相当大的损失。它 Uptime达到上百天也许你习以为常，但是只要 Down十几秒，就会立即急的满头大汗。真的很难以想象证交所宕机会怎么样，也许全国股民会闹翻天。所以我们需要一些小技巧来查找死机的原因，从而避免死机或者内核崩溃。（话说 windows天天蓝屏也没感觉呀：-o难道已经麻木了：oops：）请注意：以下方法可能不适用于 Server，因为桌面环境和 Server还是有很大区别的。 X Crash事实上 Linux内核很少出错，平常我们所遇到的“死机”都是 X无响应造成的错觉。那 X没响应了应该怎么处理呢？通常套路是 Ctrl+ Alt+F7（F8）切换到某个 tty，然后用 root登陆，执行 top查看吃资源最多的程序，然后使用 pkill/kill/killall等命令杀死该程序。或使用组合键 Ctrl+ Alt+ Backspace重启 X（黑日白月注：这个快捷键组合在最新的 Ubuntu和 Fedora中关闭）。如果偶遇切换 tty失败或者没响应，可以试着使用 SSH登陆此电脑，然后再杀死程序。也许只是 X不响应，而内核和 SSH daemon仍然工作，故此可以实施此法。 arch配置 SSH daemon万一X不给力，各种方法试了无效，又没有办法通过 SSH登陆到此 pc，那怎么办呢？别着急，我们还有万能的“reisub”大法。不过在启用前先要激活内核 sysrq功能（via）。系统启动时执行：echo“1”>/proc/sys/Kernel/sysrq或者修改/etc/sysctl.conf文件，设置 Kernel.sysrq= 1。系统异常时依次按下 Alt+sysrq+{reisub}，然后系统会自动重启。（有关 sysrq请看：Linux死机了怎么办？）不建议长按 Power按键强制关机，有可能损坏硬件或者丢失数据，甚至导致磁盘坏道！ X崩溃而内核完好常见的症状有：程序无响应，花屏，鼠标移动指针无动作，键盘输入没有识别等。但后台的音乐可以正常播放，或者键盘 Caps Lock/Num Lock/Scroll Lock按键按后对应 LED可以正常亮灭。遇到此种情况可以使用上述方法重启 X或者电脑即可恢复正常。 Application Crash这个比较常见，但是也是相当难解决的。因为 Linux上的应用软件大部分都是开源的，所以可能没有超高的稳定性。也许由于库的缺少或者版本错误，或者代码的 Bug，都有可能导致程序出现异常。一般遇到这种问题，建议检查配置文件是否正确，对配置文件的错误修改可能导致程序的运行失败。如果您确信配置文件没有错误但是程序仍然异常，可以尝试把配置文件删除（注意备份！），然后再次打开软件尝试。

由Docker BUG引起的Linux宕机事故及解决办法

1背景

某运营商业务系统的服务器发生宕机，针对本次宕机事故进行排查。

【文章福利】小编推荐自己的Linux内核源码交流群:【 869634926】整理了一些个人觉得比较好的学习书籍、视频资料共享在群文件里面，有需要的可以自行添加哦！！！前50名可进群领取，并额外赠送一份价值600的内核资料包（含视频教程、电子书、实战项目及代码)！

学习直通车： Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈

2解决过程

我们都知道kdump是在Linux系统崩溃、死锁、死机的时候用来转储内存运行参数的服务。系统崩溃后内核无法正常工作，这时kdump会产生一个用于capture当前运行信息的内核，将此时的内存中的所有运行状态和数据信息收集到vmcore文件中，收集完成后系统将自动重启。本次使用crash分析linux kdump日志。

进入crash控制台

PANIC为内核崩溃类型，这里是一个BUG，内核无法处理空指针

在crash查看log，发现有很多Out-of-Memory

通过bt查看系统崩溃前内核依次调用的一系列函数，查看内核在何处崩溃。以"#数字"开头的行为调用堆栈:

通过bt分析，可以定位到崩溃前的一个exception是ip寄存器RIP的异常，使用dis命令来看一下该地址的反汇编结果：

从上面的反汇编结果中，我们看到问题出在ip6mr.c文件1616行代码，翻开linux源码的相应位置:

撸内核源码+ Google

通过走读Linux源码和Google，发现当系统创建新的namespaces时，会因为ip6mr_sk_done的值为空而引起系统混乱，从而导致内核无法正常分配内存，所以我们在log文件中看到了许多Out-of-Memory。

在Kubernetes环境，提到namespaces就能想到docker，因为namespaces是docker的核心技术之一，容器的资源隔离由namespace来实现。

通过检查docker的网络，发现其中一个子网为空

解决办法

内核配置加入"net.ipv6.conf.all.disable_ipv6= 1",关闭 IPV6，防止触发 docker BUG；

从内核的层面看，目前该Issue仍然没有close。在开启IPv6的环境，docker为什么会出现这个BUG，后续有空再研究，欢迎大家指正。

3END

Linux内核虽然号称“不死族”,几乎不会崩溃或死机，但也有特殊情况，设备也有一定的使用周期，系统的高可用还是要的。

虽然你单点运行服务时很帅，但是你处理故障时的样子真的很狼狈。

往期精彩推荐：

最新干货！使用eBPF LSM热修复Linux内核漏洞

盘点那些Linux内核调试手段——内核打印

Linux环境下网络分析和抓包是怎么操作的？

浅谈ARM64Linux内核页表的块映射

Linux性能观测之dstat命令详解