NETSTAT 中的这些 DGRAM 项目是什么?

NETSTAT 中的这些 DGRAM 项目是什么?

我被分配了一台服务器,它一直在向我们发送大量数据,但从未使用过。所以,它很可能被入侵了。服务器上似乎没有什么问题,除了 netstat 中这些 DGRAM 项目数不胜数。

unix  2      [ ]         DGRAM                    878377447 1165/java            
unix  2      [ ]         DGRAM                    773862304 1165/java            
unix  2      [ ]         DGRAM                    690302532 1165/java            
unix  2      [ ]         DGRAM                    223108186 1165/java            
unix  2      [ ]         DGRAM                    10318852 1165/java            
unix  2      [ ]         DGRAM                    4196896942 1165/java            
unix  2      [ ]         DGRAM                    3847577732 1165/java            
unix  2      [ ]         DGRAM                    3754238011 1165/java            
unix  2      [ ]         DGRAM                    3729499062 1165/java            
unix  2      [ ]         DGRAM                    3686466054 1165/java            
unix  2      [ ]         DGRAM                    3488420039 1165/java            
unix  2      [ ]         DGRAM                    3357838223 1165/java            
unix  2      [ ]         DGRAM                    3207591570 1165/java            
unix  2      [ ]         DGRAM                    3128277321 1165/java            
unix  2      [ ]         DGRAM                    3088626078 1165/java            
unix  2      [ ]         DGRAM                    2958537971 1165/java            
unix  2      [ ]         DGRAM                    2653604223 1165/java            
unix  2      [ ]         DGRAM                    2591912878 1165/java            
unix  2      [ ]         DGRAM                    2344638274 1165/java            
unix  2      [ ]         DGRAM                    2328447790 1165/java            
unix  2      [ ]         DGRAM                    2218612906 1165/java

经过进一步调查,该进程似乎是一个 Zimbra 邮件进程。

zimbra    1165  3.1  8.2 3717464 319584 ?      Sl   Sep22 1933:59 /opt/zimbra/common/lib/jvm/java/bin/java -XX:ErrorFile=/opt/zimbra/log -client -Xmx256m -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djava.net.preferIPv4Stack=true -Dzimbra.home=/opt/zimbra -Djava.library.path=/opt/zimbra/lib -Djava.ext.dirs=/opt/zimbra/common/lib/jvm/java/jre/lib/ext:/opt/zimbra/lib/jars:/opt/zimbra/lib/ext-common:/opt/zimbra/lib/ext/clamscanner:/opt/zimbra/lib/ext/zimbra-license:/opt/zimbra/lib/ext/twofactorauth:/opt/zimbra/lib/ext/com_zimbra_ssdb_ephemeral_store -Djava.io.tmpdir=/opt/zimbra/data/tmp -Dpython.cachedir.skip=true org.python.util.jython /opt/zimbra/libexec/zmconfigd

这些是什么?为什么有这么多?有人能为我提供一些见解吗?

谢谢

答案1

这些是 Unix 数据报套接字。它们的工作方式类似于 UDP(无连接协议),但使用 unix 套接字(如/dev/log)。它们主要用于日志记录,或者用于进程/线程消息传递/同步。

zmconfigd有一个错误,导致它在无限循环中分配新的 unix dgram 套接字。

可能的原因是这样的:

  • 它是用 Python 编写的,编译为杰森,使其在 Java VM 中运行。
  • Java 不了解 Unix 套接字(标准 Java API 可能故意忽略了它,以加强跨平台兼容性)。Unix 套接字只能通过使用杰尼提。JNI 是 Java 的 C 接口,因此它不会被垃圾收集(或者,如果编写不正确,它可能会被垃圾收集器认为是意外行为)。
  • 处理 unix 套接字的 jython API 和 JVM 垃圾收集器之间可能存在一些意外的交互。

我不知道这个错误究竟何时发生。据我所知,它并没有在所有 zimbra 上发生。有可能,稍后 ​​GC 将开始工作,并且 unix dgram 套接字的创建将停止,但这可能比您当前的系统限制更大。

但是,zmconfigd它不是 Zimbra 的必要部分 - 它只会定期检查某些配置更改,并重新启动处理这些更改的 Zimbra 服务。如果您非常了解 Zimbra,则不需要它,因此您可以简单地将其关闭(不知何故 - 我不知道,如何在没有 Zimbra 黑客的情况下永久关闭单个 Zimbra 组件)。

另一个解决方法是定期重新启动 zmconfigd(zmconfigctl restart以 zimbra 用户身份每小时从 cron 运行一次)。

相关内容