我有一个 EC2 t2.micro（Linux AMI）实例。几天以来，我注意到 RAM 被 "ps" 使用了 99%。
当发生这种情况时：
$ free -m
total used free shared buff/cache available
Mem: 983 561 79 0 342 257
Swap: 0 0 0
热门节目
$ top
top - 05:58:52 up 17:28, 2 users, load average: 1.00, 0.78, 0.39
Tasks: 95 total, 1 running, 58 sleeping, 0 stopped, 0 zombie
%Cpu(s):100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1006940 total, 80816 free, 575132 used, 350992 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 263376 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14386 ec2-user 20 0 307096 269360 4192 S 99.6 26.8 7:15.88 ps
9019 ec2-user 20 0 771132 128884 47792 S 0.4 12.8 1:18.75 python
1 root 20 0 45624 5372 3936 S 0.0 0.5 0:07.01 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.05 kthreadd
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
7 root 20 0 0 0 0 S 0.0 0.0 0:00.52 ksoftirqd/0
8 root 20 0 0 0 0 I 0.0 0.0 0:03.64 rcu_sched
9 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_bh
10 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
11 root rt 0 0 0 0 S 0.0 0.0 0:00.15 watchdog/0
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
15 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns
16 root 20 0 0 0 0 I 0.0 0.0 0:00.33 kworker/u30:1
21 root 20 0 0 0 0 S 0.0 0.0 0:00.00 xenbus
22 root 20 0 0 0 0 S 0.0 0.0 0:00.06 xenwatch
172 root 20 0 0 0 0 S 0.0 0.0 0:00.01 khungtaskd
173 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper
174 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 writeback
176 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kcompactd0
177 root 25 5 0 0 0 S 0.0 0.0 0:00.00 ksmd
178 root 39 19 0 0 0 S 0.0 0.0 0:00.00 khugepaged
一旦我杀死了 ps 进程，系统就会进入正常状态。
$ free -m
total used free shared buff/cache available
Mem: 983 294 343 0 345 524
Swap: 0 0 0
[ec2-user@ip-10-0-0-86 scenAI]$ top
top - 06:05:36 up 17:35, 1 user, load average: 0.00, 0.20, 0.25
Tasks: 88 total, 1 running, 51 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 0.0 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1006940 total, 351520 free, 301488 used, 353932 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 537044 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9017 ec2-user 20 0 231592 21596 9392 S 0.3 2.1 1:32.00 uvicorn
9019 ec2-user 20 0 771132 128884 47792 S 0.3 12.8 1:19.29 python
1 root 20 0 45624 5372 3936 S 0.0 0.5 0:07.03 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.05 kthreadd
虽然我没有直接运行“ps”命令随机调用似乎正在调用它，一旦脚本失败，检查“top”显示“ps”运行在 99% CPU 。
同样以前 **ps -ef|grep ** 曾经可以工作，但现在提供 ps: unrecognized option: e ps: unrecognized option: f 。
ec2-user@xxx ~]$ top : PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18096 ec2-user 20 0 307088 4932 3992 S 99.3 0.5 0:23.54 ps
cat /proc/18096/cmdline | strings -1
[ec2-user@xxx ~]$ cat /proc/18096/cmdline | strings -1 ERROR: ld.so: object 'al/lib/libprocesshider.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'al/lib/libprocesshider.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ps
-ef
感谢任何指针。
看起来，托马斯
当你运行时cat /proc/18096/cmdline | strings -1，弹出一个奇怪的错误信息：
错误：ld.so：无法预加载来自 /etc/ld.so.preload 的对象“al/lib/libprocesshider.so”（无法打开共享对象文件）：忽略。错误：ld.so：无法预加载来自 /etc/ld.so.preload 的对象“al/lib/libprocesshider.so”（无法打开共享对象文件）：忽略。
该错误可能出现两次，因为管道中有两个命令。
虽然libprocesshider它本身是开源软件，但您通常不会在您的系统上安装它。您的系统很可能感染了恶意软件。
libprocesshider内可能出现故障ps，触发您最初观察到的问题。
最安全的方法是备份您本地可能没有的任何应用程序数据，然后从头开始重新创建 EC2 VM。
您还应该检查您的安全性。不知何故，攻击者能够写入/etc/ld.so.preload一个只能由 root 写入的文件。也许您应该为您的应用程序（而不是ec2-user帐户）创建一个仅具有最低要求权限的专用用户。如果出于某种原因，您的应用程序必须使用sudo（或某种类似的机制）以 root 身份运行命令，请确保它只能使用所需的确切参数运行它必须执行的命令。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句