进程、信号，以及 /proc 为什么是文件系统

一句话总结

“进程不会死”的症状来自四个不同的原因。要么是抓住信号而忽略它，要么处于无法抓住的状态（D），要么信号去了错误的对象，要么一开始就死了，但父母没有回收（僵尸）。区分的方法全部/proc在。

##为什么需要这个

分发脚本kill发送了，但程序还在。在这里马上kill -9的问题在于去手的动作。SIGKILL不给应用程序整理的机会。打开的文件的缓冲区不会被刷新，事务会中途中断，锁定文件会留下。向数据库或队列消费者发送SIGKILL就像拔掉电源一样。

正确的程序总是两步。发送SIGTERM，给予延期时间，但如果还活着，那就是SIGKILL。容器运行时间和Kubernetes所做的事情也是准确的，延期时间是设置值。

怎么操作

状态的一个字母是诊断的起点。

| 代码 | 含义 | 实际含义 |

| --- | --- | --- |

|R| 正在执行或等待执行 | 排队使用或接收CPU |

|S| 可中断等待 | 正常等待。可以通过信号唤醒 |

|D| 无法中断等待 | SIGKILL 也无法立即通过。 通常是磁盘或NFS |

|Z| 僵尸 | 已经死了，父母没有回收的状态 |

|T| 停止 | 收到SIGSTOP或SIGTSTP |D如果看到，信号无法解决。内核在等待什么/proc/<PID>/wchan伊娜/proc/<PID>/stack应该从那里看。

**SIGKILL和SIGSTOP不能被捕获、阻止或忽略。**剩下的信号全部可以让应用程序改变处理方式。所以kill -TERM存在这种无法通用的程序，它可能不是错误，而是设计。抓住什么样的信号/proc/<PID>/status的SigCgt·SigBlk·SigIgn直接写在比特币上。

/proc这个文件系统的理由。要向用户空间显示内核的内部数据结构，就要大量创建新的系统调用，或者重新使用现有的接口。Unix选择了后者。所以进程信息是cat被读取为，打开的文件描述符是/proc/<PID>/fd/如下显示为符号链接，将该链接直接cp这样做的话，也会恢复被删除的文件。资源限制是/proc/<PID>/limits在，我的壳的ulimit不是这样，可以确认那个过程实际上收到的限额。

nice和ulimit都继承。 nice值在-20到19之间，越低优先级越高。普通用户只能提高值，不能降低。ulimit的soft限制可以在hard限制以下自由调整，但只有root才能提高hard限制。而且两个值都直接继承到子进程中，所以在shell中降低一次的限制会跟着低于该限制的所有进程。很多时候“为什么只有这个守护程序不能打开文件”的答案就在这里。

在现场相遇的样子

作者整理的systemd问题案例中，有三个特别经常出现。第一，Restart=on-failure如果不限制每次点击后重新启动，就会因为设置错误而崩溃的服务会进入无限重新启动，烧毁CPU，用日志填满磁盘。限制StartLimitIntervalSec科StartLimitBurst是[Service]不是去**[Unit]部分**指令词，如果放在错误的部分的话，会被安静地忽略。

第二，ExecStart=因为systemd不会经过shell，而是直接运行。如果需要shell功能，就必须明确地运行shell，并且最好将日志发送到日志文件中作为标准输出。第三，退出代码上写着原因——203/EXEC是执行路径错误或没有执行权限，217/USER是User=没有写在上的账户。

容器方面还有一个陷阱。如果以shell格式写命令，shell将成为PID 1，应用程序将成为它的子程序。这时SIGTERM会去找shell，shell不会把它传达给子程序，所以应用程序一次也没有得到延期，而是被SIGKILL杀死。

##下次实习要做的事情

在这个实习环境中systemctl这个动作不做。所以服务实习集中在准确使用单元文件上。部分构成和执行·重新启动指令、计时器单元，/etc/cron.d涵盖了用户crontab的格式差异、cron的短PATH问题、日志轮换设置，以及在drop-in覆盖中清空列表型指令的惯例。在接下来的练习中，整理启动顺序和GRUB设置，/proc直接读取，向后台进程发送信号，确认状态变化。