Linux OOM | Early OOM | 进程监视

注： 本文为 “Linux OOM” 相关文章合辑。

---

Linux OOM 终结者

译者：花名有孚

| 2015-07-21 08:47

现在是早晨 6 点钟。已经醒来的我正在总结到底是什么事情使得我的起床闹铃提前了这么多。我们的监控系统显示，Plumbr 服务出故障了。

现在我可以开始处理故障了。首先要怀疑的是应用程序本身，因为它在崩溃之前一点异常也没有。应用程序日志中没有错误，没有警告，也没有任何可疑的信息。

我们部署的监控系统发现进程已经挂掉了并重启了服务。30 分钟后，我在 /var/log/kern.log 日志中发现了下面的信息：

Jun  4 07:41:59 plumbr kernel: [70667120.897649] Out of memory: Kill process 29957 (java) score 366 or sacrifice child
Jun  4 07:41:59 plumbr kernel: [70667120.897701] Killed process 29957 (java) total-vm:2532680kB, anon-rss:1416508kB, filers:0kB

很明显我们被 Linux 内核给坑了。Linux 里面许多守护进程是由几个内核作业所看管的，其中的一个犹为恶毒。所有的现代 Linux 内核中都会有一个内存不足终结者（Out of memory Killer, OOM Killer）的内建机制，在内存过低的情况下，它会杀掉你的进程。当探测到这一情况时，这个终结者会被激活，然后挑选出一个进程去终结掉。选择目标进程使用的是一套启发式算法，它会计算所有进程的分数，然后选出那个分数最低的进程。

理解 OOM Killer

默认情况下，Linux 内核会允许进程请求的内存超出实际可用内存的大小。这在现实世界中是有意义的，因为大多数进程其实并不会用到所有分配给它的内存（注：同一时间内不会全用到）。和这个问题最类似的就是运营商了。他们承诺卖给用户的都是 100Mb 的带宽，这实际上远远超出了他们的网络容量。他们赌的就是用户实际上并不会同时用完分配给他们的下载上限。一个 10Gb 的连接可以很轻松地承载 100 个以上的用户，这里的 100 是通过简单的数学运算得出的（10G/100M）。

这个做法的一个很明显的副作用就是，万一有一个程序正走上了一条耗尽内存的不归路怎么办。这会导致低可用内存的情况，也就是没有内存页能够再分配给进程了。你可能也碰到过这种情况，没有 root 帐户你是杀不掉这种顽固的进程的。为了解决这一情况，终结者被激活了，并找出了要终结的进程。

关于 “Out of memory killer” 参数的调整，可以参考下 这篇文章

• Capacity Tuning | Red Hat Product Documentation
  https://docs.redhat.com/en/documentation/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-captun.html

是谁触发了 OOM Killer？

虽然现在已经知道发生了什么，但还是搞不清楚到底是谁触发了这个终结者，然后在早晨 5 点钟把我吵醒。进一步的分析后找到了答案：

• /proc/sys/vm/overcommit_memory 中的配置允许内存的超量使用 —— 该值设置为 1，这意味着每个 malloc () 请求都会成功。

• 应用程序运行在一台 EC2 m1.small 的实例上。EC2 的实例默认是禁用了交换分区的。

这两个因素正好又赶上了我们服务的突然的流量高峰，最终导致应用程序为了支持这些额外的用户而不断请求更多的内存。内存超量使用的配置允许这个贪心的进程不停地申请内存，最后会触发这个内存不足的终结者，它就是来履行它的使命的。去杀掉了我们的程序，然后在大半夜把我给叫醒。

示例

当我把这个情况描述给工程师的时候，有一位工程师觉得很有意思，因此写了个小的测试用例来重现了这个问题。你可以在 Linux 下编译并运行下面这个代码片段（我是在最新的稳定版 Ubuntu 上运行的）。

  package eu.plumbr.demo;public class OOM {public static void main(String[] args){java.util.List l = new java.util.ArrayList();for (int i = 10000; i < 100000; i++) {try {l.add(new int[100_000_000]);} catch (Throwable t) {t.printStackTrace();}}}}

然后你就会发现同样的一个 Out of memory: Kill process (java) score or sacrifice child 信息。

注意的是，你可能得调整下交换分区以及堆的大小，在我这个测试用例中，我通过 -Xm2g 设置了2G大小的堆，同时交换内存使用的是如下的配置：

swapoff -a
dd if=/dev/zero of=swapfile bs=1024 count=655360
mkswap swapfile
swapon swapfile

解决方案

这种情况有好几种解决方案。在我们这个例子中，我们只是把系统迁移到了一台内存更大的机器上，我也考虑过激活交换分区，不过咨询了工程师之后我想起来 JVM 上的 GC 进程在交换分区下的表现并不是很理想，因此这个选项就作罢了。

还有别的一些方法比如 OOM killer 的调优，或者将负载水平分布到数个小的实例上，又或者减少应用程序的内存占用量。

---

Early OOM：在无响应的 Linux 系统中杀掉内存消耗最大的进程

作者：Aditya Goturu

译者： LCTT ShenYu Zheng

| 2018-05-31 09:21

有时候，我在浏览器中开启了非常多的标签页，导致操作系统会无响应好几分钟。我不能移动我的鼠标，也不能杀掉一个进程或关闭任何开启的标签页。在这种情况下，我别无选择，只能强制重启系统。当然我也用了 OneTab （LCTT 译注：OneTab 是一个 Chrome 的 Extension，可以将标签页转化成一个列表保存。）和 Greate Suspender （LCTT 译注：Great Suspender 是一个 Chrome 的 Extension，可以自动冻结标签页）这样浏览器拓展，但它们在这里也起不到太大的作用。我经常耗尽我的内存。而这就是 Early OOM 起作用的时候了。在情况严重时，它会杀掉一个未响应系统中的内存消耗最大的进程。Early OOM 每秒会检测可用内存和空余交换区 10 次，一旦两者都低于 10%，它就会把最大的进程杀死。

为什么用 Early OOM 而不用系统内置的 OOM killer？

在继续讨论下去之前，我想先简短的介绍下 OOM killer，也就是 Out Of Memory killer。OOM killer 是一个由内核在可用内存非常低的时候使用的进程。它的主要任务是不断的杀死进程，直到释放出足够的内存，使内核正在运行的其它进程能顺利运行。OOM killer 会找到系统中最不重要并且能释放出最多内存的进程，然后杀掉他们。在 /proc 目录下的 pid 目录中，我们可以看到每个进程的 oom_score。

示例：

$ cat /proc/10299/oom_score1

一个进程的 oom_score 的值越高，这个进程越有可能在系统内存耗尽的时候被 OOM killer 杀死。

Early OOM 的开发者表示，相对于内置的 OOM killer，Early OOM 有一个很大的优点。就像我之前说的那样，OOM killer 会杀掉 oom_score 最高的进程，而这也导致 Chrome 浏览器总是会成为第一个被杀死的进程。为了避免这种情况发生，Early OOM 使用 /proc/*/status 而不是 echo f > /proc/sysrq-trigger（LCTT 译注：这条命令会调用 OOM killer 杀死进程）。开发者还表示，手动触发 OOM killer 在最新版本的 Linux 内核中很可能不会起作用。

安装 Early OOM

Early OOM 在 AUR（Arch User Repository）中可以找到，所以你可以在 Arch 和它的衍生版本中使用任何 AUR 工具安装它。

使用 Pacaur：

pacaur -S earlyoom

使用 Packer：

packer -S earlyoom

使用 Yaourt：

yaourt -S earlyoom

启用并启动 Early OOM 守护进程：

sudo systemctl enable earlyoom
sudo systemctl start earlyoom

在其它的 Linux 发行版中，可以按如下方法编译安装它：

git clone https://github.com/rfjakob/earlyoom.git
cd earlyoom
make
sudo make install

Early OOM - 杀掉无响应 Linux 系统中的最大的进程

运行如下命令启动 Early OOM：

earlyoom

如果是通过编译源代码安装的，运行如下命令启动 Early OOM：

./earlyoom

示例输出：

earlyoom 0.12
mem total: 3863 MiB, min: 386 MiB (10 %)
swap total: 2047 MiB, min: 204 MiB (10 %)
mem avail: 1770 MiB (45 %), swap free: 2047 MiB (99 %)
mem avail: 1773 MiB (45 %), swap free: 2047 MiB (99 %)
mem avail: 1772 MiB (45 %), swap free: 2047 MiB (99 %)
mem avail: 1773 MiB (45 %), swap free: 2047 MiB (99 %)
mem avail: 1772 MiB (45 %), swap free: 2047 MiB (99 %)
mem avail: 1773 MiB (45 %), swap free: 2047 MiB (99 %)
mem avail: 1771 MiB (45 %), swap free: 2047 MiB (99 %)
mem avail: 1773 MiB (45 %), swap free: 2047 MiB (99 %)
mem avail: 1784 MiB (46 %), swap free: 2047 MiB (99 %)
[...]

就像你在上面的输出中可以看到的，Early OOM 将会显示你有多少内存和交换区，以及有多少可用的内存和交换区。记住它会一直保持运行，直到你按下 CTRL+C。

如果可用的内存和交换区大小都低于 10%，Early OOM 将会自动杀死最大的进程，直到系统有足够的内存可以流畅的运行。你也可以根据你的需求配置最小百分比值。

设置最小的可用内存百分比，运行：

earlyoom -m <PERCENT_HERE>

设置最小可用交换区百分比, 运行：

earlyoom -s <PERCENT_HERE>

在帮助部分，可以看到更多详细信息：

$ earlyoom -h
earlyoom 0.12
Usage: earlyoom [OPTION]...
-m PERCENT set available memory minimum to PERCENT of total (default 10 %)
-s PERCENT set free swap minimum to PERCENT of total (default 10 %)
-M SIZE set available memory minimum to SIZE KiB
-S SIZE set free swap minimum to SIZE KiB
-k use kernel oom killer instead of own user-space implementation
-i user-space oom killer should ignore positive oom_score_adj values
-d enable debugging messages
-v print version information and exit
-r INTERVAL memory report interval in seconds (default 1), set to 0 to
disable completely
-p set niceness of earlyoom to -20 and oom_score_adj to -1000
-h this help text

现在，你再也不用担心内存消耗最高的进程了。

—

via: https://www.ostechnix.com/kill-largest-process-unresponsive-linux-system/

作者：Aditya Goturu 译者：cizezsy 校对：wxy

---

在 Linux/Unix/Windows 中发现隐藏的进程和端口

作者：Vivek Gite

译者： LCTT fan Li

| 2018-01-28 22:27

unhide 是一个小巧的网络取证工具，能够发现那些借助 rootkit、LKM 及其它技术隐藏的进程和 TCP/UDP 端口。这个工具在 Linux、UNIX 类、MS-Windows 等操作系统下都可以工作。根据其 man 页面的说明：

Unhide 通过下述三项技术来发现隐藏的进程。

1. 进程相关的技术，包括将 /proc 目录与 /bin/ps 命令的输出进行比较。
2. 系统相关的技术，包括将 /bin/ps 命令的输出结果同从系统调用方面得到的信息进行比较。
3. 穷举法相关的技术，包括对所有的进程 ID 进行暴力求解，该技术仅限于在基于 Linux2.6 内核的系统中使用。

绝大多数的 Rootkit 工具或者恶意软件借助内核来实现进程隐藏，这些进程只在内核内部可见。你可以使用 unhide 或者诸如rkhunter 等工具，扫描 rootkit 程序 、后门程序以及一些可能存在的本地漏洞 .。

这篇文章描述了如何安装 unhide 并搜索隐藏的进程和 TCP/UDP 端口。

安装 unhide

首先建议你在只读介质上运行这个工具。如果使用的是 Ubuntu 或者 Debian 发行版，输入下述的 apt-get/apt 命令以安装 Unhide：

$ sudo apt-get install unhide

一切顺利的话你的命令行会输出以下内容：

[sudo] password for vivek:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
rkhunter
The following NEW packages will be installed:
unhide
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 46.6 kB of archives.
After this operation, 136 kB of additional disk space will be used.
Get:1 http://in.archive.ubuntu.com/ubuntu artful/universe amd64 unhide amd64 20130526-1 [46.6 kB]
Fetched 46.6 kB in 0s (49.0 kB/s)
Selecting previously unselected package unhide.
(Reading database ... 205367 files and directories currently installed.)
Preparing to unpack .../unhide_20130526-1_amd64.deb ...
Unpacking unhide (20130526-1) ...
Setting up unhide (20130526-1) ...
Processing triggers for man-db (2.7.6.1-2) ...

在 RHEL/CentOS/Oracle/Scientific/Fedora 上安装 unhide

输入下列 yum Type the following yum command (first turn on EPLE repo on a CentOS/RHEL version 6.x or version 7.x):

输入以下的 yum 命令（CentOS/RHEL 6.x 或 7.x 上首先打开 EPEL 仓库）：

$ sudo yum install unhide

在 Fedora 上则使用以下 dnf 命令：

$ sudo dnf install unhide

在 Arch 上安装 unhide

键入以下 pacman 命令安装：

$ sudo pacman -S unhide

在 FreeBSD 上安装 unhide

可以通过以下的命令使用 port 来安装 unhide：

# cd /usr/ports/security/unhide/
# make install clean

或者可以通过二进制文件安装 hide，使用 pkg 命令安装：

# pkg install unhide

使用 unhide 工具

unhide 的语法是：

unhide [options] test_list

test_list 参数可以是以下测试列表中的一个或者多个标准测试：

1. brute
2. proc
3. procall
4. procfs
5. quick
6. reverse
7. sys

或基本测试：

1. checkbrute
2. checkchdir
3. checkgetaffinity
4. checkgetparam
5. checkgetpgid
6. checkgetprio
7. checkRRgetinterval
8. checkgetsched
9. checkgetsid
10. checkkill
11. checknoprocps
12. checkopendir
13. checkproc
14. checkquick
15. checkreaddir
16. checkreverse
17. checksysinfo
18. checksysinfo2
19. checksysinfo3

你可以通过以下示例命令使用 unhide：

# unhide proc
# unhide sys
# unhide quick

示例输出：

Unhide 20130526
Copyright © 2013 Yago Jesus & Patrick Gouin
License GPLv3+ : GNU GPL version 3 or later
http://www.unhide-forensics.info
NOTE : This version of unhide is for systems using Linux >= 2.6
Used options:
[*]Searching for Hidden processes through comparison of results of system calls, proc, dir and ps

使用 unhide-tcp 工具辨明 TCP/UDP 端口的身份

以下是来自 man 页面的介绍：

unhide-tcp 取证工具通过对所有可用的 TCP/IP 端口进行暴力求解的方式，辨别所有正在监听，却没有列入 /bin/netstat 或者 /bin/ss 命令输出的 TCP/IP 端口身份。

注一：对于 FreeBSD、OpenBSD系统，一般使用 netstat 命令取代在这些操作系统上不存在的 iproute2，此外，sockstat 命令也用于替代 fuser。

注二：如果操作系统不支持 iproute2 命令，在使用 unhide 时需要在命令上加上 -n 或者 -s 选项。

# unhide-tcp

示例输出：

Unhide 20100201
http://www.security-projects.com/?Unhide
Starting TCP checking
Starting UDP checking

上述操作中，没有发现隐藏的端口。

但在下述示例中，我展示了一些有趣的事。

# unhide-tcp

示例输出：

Unhide 20100201
http://www.security-projects.com/?Unhide
Starting TCP checking
Found Hidden port that not appears in netstat: 1048
Found Hidden port that not appears in netstat: 1049
Found Hidden port that not appears in netstat: 1050
Starting UDP checking

可以看到 netstat -tulpn 和 ss 命令确实没有反映出这三个隐藏的端口：

# netstat -tulpn | grep 1048
# ss -lp
#ss -l | grep 1048

通过下述的 man 命令可以更多地了解 unhide：

$ man unhide
$ man unhide-tcp

Windows 用户如何安装使用 unhide

可以通过

-Unhide homepage - Download
https://www.unhide-forensics.info/?Windows:Download

获取 Windows 版本的 unhide。

—

via: https://www.cyberciti.biz/tips/linux-unix-windows-find-hidden-processes-tcp-udp-ports.html

作者：Vivek Gite 译者：ljgibbslf 校对：wxy

---

进程监视

作者：Andrew

译者：LCTT qhwdw

| 2018-04-23 12:41

由于复刻了 mon 项目到 etbemon 中，我花了一些时间做监视脚本。事实上监视一些事情通常很容易，但是决定监视什么才是困难的部分。进程监视脚本 ps.monitor 是我重新设计过的一个。

对于进程监视我有一些思路。如果你对进程监视如何做的更好有任何建议，请通过评论区告诉我。

给不使用 mon 的人介绍一下，如果一切 OK 该监视脚本就返回 0，而如果有问题它会返回 1，并使用标准输出显示错误信息。虽然我并不知道有谁将 mon 脚本挂进一个不同的监视系统中，但是，那样做其实很容易实现。我计划去做的一件事情就是，将来实现 mon 和其它的监视系统如 Nagios 之间的互操作性。

基本监视

ps.monitor tor:1-1 master:1-2 auditd:1-1 cron:1-5 rsyslogd:1-1 dbus-daemon:1- sshd:1- watchdog:1-2

我现在计划重写该进程监视脚本的某些部分。现在的功能是在命令行上列出进程名字，它包含了要监视的进程的最小和最大实例数量。上面的示例是一个监视的配置。在这里有一些限制，在这个实例中的 master 进程指的是 Postfix 的主进程，但是其它的守护进程使用了相同的进程名（这是那些错误的名字之一，因为它太直白了）。一个显而易见的解决方案是，给一个指定完整路径的选项，这样，那个 /usr/lib/postfix/sbin/master 就可以与其它命名为 master 的程序区分开了。

下一个问题是那些可能以多个用户身份运行的进程。比如 sshd，它有一个以 root 身份运行的单独的进程去接受新的连接请求，以及在每个登入用户的 UID 下运行的进程。因此，作为 root 用户运行的 sshd 进程的数量将比 root 登录会话的数量大 1。这意味着如果一个系统管理员直接以 root 身份通过 ssh 登入系统（这是有争议的，但它不是本文的主题—— 只是有些人需要这样做，所以我们必须支持这种情形），然后 master 进程崩溃了（或者系统管理员意外或者故意杀死了它），这时对于该进程丢失并不会产生警报。当然正确的做法是监视 22 号端口，查找字符串 SSH-2.0-OpenSSH_。有时候，守护进程的多个实例运行在需要单独监视的不同 UID 下面。因此，我们需要通过 UID 监视进程的能力。

在许多情形中，进程监视可以被替换为对服务端口的监视。因此，如果在 25 号端口上监视，那么有可能意味着，Postfix 的 master 在运行着，不用去理会其它的 master 进程。但是对于我而言，我可以在方便地进行多个监视，如果我得到一个关于无法向一个服务器发送邮件的 Jabber 消息，我可以通过这个来自服务器的 Jabber 消息断定 master 没有运行，而不需要挨个查找才能发现问题所在。

SE Linux

我想要的一个功能就是，监视进程的 SE Linux 上下文，就像监视 UID 一样。虽然我对为其它安全系统编写一个测试不感兴趣，但是，我很乐意将别人写好的代码包含进去。因此，不管我做什么，都希望它能与多个安全系统一起灵活地工作。

短暂进程

大多数守护进程在进程启动期间都有一个相同名字的次级进程second process。这意味着如果你为了精确地监视一个进程的一个实例，当 logrotate 或者类似的守护进程重启时，你或许会收到一个警报说有两个进程运行。如果在重启期间，恰好在一个错误的时间进行检查，你也或许会收到一个警报说，有 0 个实例。我现在处理这种情况的方法是，在与 alertafter 2 指令一起的次级进程失败事件之前我的服务器不发出警报。当监视处于一个失败的状态时，failure_interval 指令允许指定检查的时间间隔，将其设置为一个较低值时，意味着在等待一个次级进程失败结果时并不会使提示延迟太多。

为处理这种情况，我考虑让 ps.monitor 脚本在一个指定的延迟后再次进行自动检查。我认为使用一个单个参数的监视脚本来解决这个问题比起使用两个配置指令的 mon 要好一些。

CPU 使用

mon 现在有一个 loadavg.monitor 脚本，它用于检查平均负载。但是它并不能捕获一个单个进程使用了太多的 CPU 时间而没有使系统平均负载上升的情况。同样，也没有捕获一个渴望获得 CPU 的进程进入沉默（例如，SETI at Home 停止运行）（LCTT 译注：SETI，由加州大学伯克利分校创建的一项利用全球的联网计算机的空闲计算资源来搜寻地外文明的科学实验计划），而其它的进程进入一个无限循环状态的情况。解决这种问题的一个方法是，让 ps.monitor 脚本也配置另外的一个选项去监视 CPU 的使用，但是这也可能会让人产生迷惑。另外的选择是，使用一个独立的脚本，它用来报警任何在它的生命周期或者最后几秒中，使用 CPU 时间超过指定百分比的进程，除非它在一个豁免这种检查的进程或用户的白名单中。或者每个普通用户都应该豁免这种检查，因为你压根就不知道他们什么时候运行一个文件压缩程序。也应该有一个包含排除的守护进程（像 BOINC）和系统进程（像 gzip，有几个定时任务会运行它）的简短列表。

对例外的监视

一个常见的编程错误是在 setgid() 之前调用 setuid()，这意味着那个程序没有权限去调用 setgid()。如果没有检查返回代码（而犯这种低级错误的人往往不会去检查返回代码），那么进程会保持较高的权限。检查以 GID 0 而不是 UID 0 运行的进程是很方便的。顺利说一下，对一个 Debian/Testing 工作站运行的一个快速检查显示，一个使用 GID 0 的进程并没有获得较高的权限，但是可以使用一个 chmod 770 命令去改变它。

在一个 SE Linux 系统上，应该只有一个进程与 init_t 域一起运行。目前在运行守护进程（比如，mysqld 和 tor）的 Debian Stretch 系统中，并不会发生策略与守护进程服务文件所请求的 systemd 的最新功能不匹配的情况。这样的问题将会不断发生，我们需要对它进行自动化测试。

对配置错误的自动测试可能会影响系统安全，这是一个很大的问题，我将来或许写一篇关于这方面的单独的博客文章。

—

via: https://etbe.coker.com.au/2017/09/28/process-monitoring/

作者：Andrew 译者：qhwdw 校对：wxy

---

via:

由 LCTT 原创编译，Linux中国 荣誉推出