禅城网站建设报价,建筑企业资质查询系统,网站建设加盟创业,企业如何注册域名注#xff1a; 本文为 “Linux OOM” 相关文章合辑。 Linux OOM 终结者
译者#xff1a;花名有孚
| 2015-07-21 08:47
现在是早晨 6 点钟。已经醒来的我正在总结到底是什么事情使得我的起床闹铃提前了这么多。我们的监控系统显示#xff0c;Plumbr 服务出故障了。
现在我…注 本文为 “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 ofswapfile bs1024 count655360
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 killerEarly OOM 有一个很大的优点。就像我之前说的那样OOM killer 会杀掉 oom_score 最高的进程而这也导致 Chrome 浏览器总是会成为第一个被杀死的进程。为了避免这种情况发生Early OOM 使用 /proc/*/status 而不是 echo f /proc/sysrq-triggerLCTT 译注这条命令会调用 OOM killer 杀死进程。开发者还表示手动触发 OOM killer 在最新版本的 Linux 内核中很可能不会起作用。
安装 Early OOM
Early OOM 在 AURArch 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 installEarly 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 将会显示你有多少内存和交换区以及有多少可用的内存和交换区。记住它会一直保持运行直到你按下 CTRLC。
如果可用的内存和交换区大小都低于 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 通过下述三项技术来发现隐藏的进程。 进程相关的技术包括将 /proc 目录与 /bin/ps 命令的输出进行比较。系统相关的技术包括将 /bin/ps 命令的输出结果同从系统调用方面得到的信息进行比较。穷举法相关的技术包括对所有的进程 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_listtest_list 参数可以是以下测试列表中的一个或者多个标准测试
bruteprocprocallprocfsquickreversesys
或基本测试
checkbrutecheckchdircheckgetaffinitycheckgetparamcheckgetpgidcheckgetpriocheckRRgetintervalcheckgetschedcheckgetsidcheckkillchecknoprocpscheckopendircheckproccheckquickcheckreaddircheckreversechecksysinfochecksysinfo2checksysinfo3
你可以通过以下示例命令使用 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-tcpWindows 用户如何安装使用 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中国 荣誉推出
