conmon 2.0.29 exec会话僵尸进程根因分析

发表于 2026-07-06 分类于 MISC

问题现象

我们的程序通过 podman exec 在容器中周期性执行命令，偶尔会出现命令进程退出后成为僵尸进程zombie，一直不被回收。查看进程关系，僵尸进程的父进程为conmon。此时conmon进程阻塞在poll() 系统调用，无法回收已退出的命令进程。

[root@dev05 ~]# ps -ef |grep 1580889
root     1580889       1  0 Jul02 ?        00:00:00 /usr/bin/conmon --api-version 1 -c c6b34b14a6622562eb4b076c021c52ba9f55746cd51849638126577328c798a5 -u 98aaaceda2866ee23fc0a5e2e355c696bbb5d9810104331efdacaf31ea33cdcd -r /usr/bin/runc -b /var/lib/containers/storage/overlay-containers/c6b34b14a6622562eb4b076c021c52ba9f55746cd51849638126577328c798a5/userdata/98aaaceda2866ee23fc0a5e2e355c696bbb5d9810104331efdacaf31ea33cdcd -p /var/lib/containers/storage/overlay-containers/c6b34b14a6622562eb4b076c021c52ba9f55746cd51849638126577328c798a5/userdata/98aaaceda2866ee23fc0a5e2e355c696bbb5d9810104331efdacaf31ea33cdcd/exec_pid -n tomcat --exit-dir /var/lib/containers/storage/overlay-containers/c6b34b14a6622562eb4b076c021c52ba9f55746cd51849638126577328c798a5/userdata/98aaaceda2866ee23fc0a5e2e355c696bbb5d9810104331efdacaf31ea33cdcd/exit --full-attach -l none --log-level warning --runtime-arg --log-format=json --runtime-arg --log --runtime-arg=/var/lib/containers/storage/overlay-containers/c6b34b14a6622562eb4b076c021c52ba9f55746cd51849638126577328c798a5/userdata/98aaaceda2866ee23fc0a5e2e355c696bbb5d9810104331efdacaf31ea33cdcd/oci-log -i -e --exec-attach --exec-process-spec /var/lib/containers/storage/overlay-containers/c6b34b14a6622562eb4b076c021c52ba9f55746cd51849638126577328c798a5/userdata/98aaaceda2866ee23fc0a5e2e355c696bbb5d9810104331efdacaf31ea33cdcd/exec-process-454711737 --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /var/lib/containers/storage --exit-command-arg --runroot --exit-command-arg /run/containers/storage --exit-command-arg --log-level --exit-command-arg warning --exit-command-arg --cgroup-manager --exit-command-arg cgroupfs --exit-command-arg --tmpdir --exit-command-arg /run/libpod --exit-command-arg --runtime --exit-command-arg runc --exit-command-arg --storage-driver --exit-command-arg overlay --exit-command-arg --storage-opt --exit-command-arg overlay.mountopt=nodev,metacopy=on --exit-command-arg --events-backend --exit-command-arg file --exit-command-arg container --exit-command-arg cleanup --exit-command-arg --exec --exit-command-arg 98aaaceda2866ee23fc0a5e2e355c696bbb5d9810104331efdacaf31ea33cdcd --exit-command-arg c6b34b14a6622562eb4b076c021c52ba9f55746cd51849638126577328c798a5
root     1580901 1580889  0 Jul02 ?        00:00:00 [md5sum] <defunct>
[root@dev05 tmp]# cat /proc/1580889/stack
[<0>] poll_schedule_timeout.constprop.14+0x42/0x70
[<0>] do_sys_poll+0x493/0x520
[<0>] __x64_sys_poll+0x37/0x130
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x65/0xca

阅读全文 »

执行nginx -t修改临时目录属主

发表于 2026-01-04 分类于 NGINX

nginx以root启动时，如果配置文件中没有指定user指令，那么默认会设定user为nobody, 数字为65534。而如果使用非root用户启动，那么nginx则不处理用户，直接以当前用户启动worker进程。

nginx的启动过程中的函数ngx_init_cycle会调用函数ngx_create_paths创建临时文件目录。在创建目录后，也会对目录的属主进行处理。如果属主不同于user指令配置的用户，那么就会调用chown更改属主为user配置的用户。

在执行nginx -t时，nginx也会调用函数ngx_init_cycle, 也就是在执行nginx -t时也有可能更改临时目录的属主，从而导致在运行的nginx worker进程没有权限读取临时目录导致业务异常。

比如，以nginx用户启动nginx, 此时临时目录属主为nginx。

1 2	nginx 273095 0.0 0.0 26788 384 ? Ss 10:11 0:00 nginx: master process ./sbin/nginx nginx 273096 0.0 0.0 27156 1948 ? S 10:11 0:00 nginx: worker process

[nginx@dev02 nginx]$ ls -l
total 4
drwx------. 2 nginx nginx    6 Dec 18 10:10 client_body_temp
drwxr-xr-x. 2 nginx root  4096 Dec 18 10:11 conf
drwx------. 2 nginx nginx    6 Dec 18 10:10 fastcgi_temp
drwxr-xr-x. 2 nginx root    40 Oct 24 17:22 html
drwxr-xr-x. 2 nginx root    58 Dec 18 10:11 logs
drwx------. 2 nginx nginx    6 Dec 18 10:10 proxy_temp
drwxr-xr-x. 2 nginx root    48 Dec 18 10:07 sbin
drwx------. 2 nginx nginx    6 Dec 18 10:10 scgi_temp
drwx------. 2 nginx nginx    6 Dec 18 10:10 uwsgi_temp

阅读全文 »

Docker容器数据包转发路径分析

发表于 2025-11-22 更新于 2026-01-04 分类于 Kernel

这些年总结过多次容器网络数据包路径相关的文章, 如:

但每次过段时间后，总会忘记细节。分析容器网络异常是否是由于某些基于netfilter的驱动影响时，总是要重新梳理。这次再从内核实现的角度来分析一次容器网络数据包的转发路径。

还是以外部访问bridge模式docker容器的场景进行分析。

入包

外部主机访问docker容器的数据包到达网卡后, 由内核函数:netif_receive_skb处理进入协议栈处理。对于IP数据包，会调用到函数ip_rcv：

1
2
3

return NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING, NULL, skb,
           dev, NULL,
           ip_rcv_finish);

在这里会进行netfilter的PRE_ROUTING阶段处理。入包在PRE_ROUTING阶段会由docker的iptables规则完成DNAT操作，数据包目的IP变更为docker容器的IP。

阅读全文 »

crash脚本工具crash-lua

发表于 2025-07-03 更新于 2026-01-04 分类于 MISC

crash是一个用于分析Linux内核转储文件(vmcore)的工具。正在运行的内核安装上debuginfo包之后，直接运行crash也可以直接分析运行中的内核，这对于分析一些内核问题极为有用。

在我们的某个场景中，需要分析NFQUEUE队列中的数据包内容。队列在内核中的表示是结构体nfqnl_instance，数据包sk_buff通过nf_queue_entry结构链在队列nfqnl_instance中。

要找到对应的nfqnl_instance，需要执行多条crash命令:

阅读全文 »

NFQUEUE机制导致DNS请求超时

发表于 2025-06-18 更新于 2026-01-04 分类于 Kernel

之前的文章<<NFQUEUE机制导致DNS请求5秒超时分析>>分析过在3.10.0-1015.el7版本之前的内核上，conntrack模块在插入条目时存在竞争条件，使用NFQUEUE机制导致AAAA请求包被丢弃，从而导致DNS请求出现5秒超时的现象。当时给的解决方案是可以在/etc/resolv.conf中添加options single-request-reopen来规避。

最近又遇到这个问题，但该规避方案并没有生效，因而做了进一步分析，发现glibc的DNS行为在不同响应上有所不同。

在没有NFQUEUE机制也没有开启single-request-reopen的环境中，访问正常解析的域名, 如:

[root@dev07 ~]# time curl -s www.baidu.com -o /dev/null

real	0m1.009s
user	0m0.003s
sys	0m0.003s

抓包结果为:

16:29:40.344792 IP 10.10.0.7.34972 > 10.10.0.2.53: 20510+ A? www.baidu.com. (31)
16:29:40.344832 IP 10.10.0.7.34972 > 10.10.0.2.53: 42033+ AAAA? www.baidu.com. (31)
16:29:40.345097 IP 10.10.0.2.53 > 10.10.0.7.34972: 20510 3/0/0 CNAME www.a.shifen.com., A 110.242.70.57, A 110.242.69.21 (90)
16:29:40.345308 IP 10.10.0.2.53 > 10.10.0.7.34972: 42033 3/0/0 CNAME www.a.shifen.com., AAAA 2408:871a:2100:1b23:0:ff:b07a:7ebc, AAAA 2408:871a:2100:186c:0:ff:b07e:3fbc (114)

可以看到resolver同时发出A和AAAA两个请求。

阅读全文 »

关于nginx中的limit_conn指令

发表于 2025-06-18 更新于 2026-01-04 分类于 NGINX

多年前写过介绍nginx限制连接模块的文章<<ngx_http_limit_conn_module模块分析>>, 最近业务中用到limit_conn指令限制请求，重新了解了一下它的用法。

根据nginx文档, 可以理解主要逻辑是根据limit_conn_zone所指定的key值计算连接数，当连接数超过limit_conn所指定的值时，则返回错误码。

由于限制值是在limit_conn指令而不是在limit_conn_zone指令中设置的，而limit_conn是可以配置多次的，当配置多次相同zone的limit_conn指令并且限制值不同，那么生效的是哪个限制值呢？

如果在同一个location中配置多个相同zone的limit_conn指令，示例配置为:

location /a {
    limit_conn perserver 2;
    limit_conn perserver 5;
    ...
}

阅读全文 »

相同网桥上的网络隔离

发表于 2025-03-19 更新于 2026-01-04 分类于 Network

我们的oVirt虚拟化平台上有一个需求，需要对同一网桥上的虚拟机之间进行网络隔离。

参考Docker实现中对于不同网桥的网络隔离，可以简单的采用iptables规则来实现。

Docker在iptables的filter表的FORWARD链的规则如下:

[root@localhost ~]# iptables -nL -v
Chain INPUT (policy ACCEPT 90 packets, 6017 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER-USER  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 DOCKER-ISOLATION-STAGE-1  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 109 packets, 6560 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER-ISOLATION-STAGE-2  all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER-USER (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

阅读全文 »

关于参数net.netfilter.nf_conntrack_max

发表于 2025-02-11 更新于 2026-01-04 分类于 Kernel

Linux内核中conntrack模块使用哈希表来存储连接跟踪条目，当哈希表条目达到上限时，系统会将新分配conntrack条目的数据包DROP掉，从而导致网络受到影响。此时，日志中会记录:

1	nf_conntrack: table full, dropping packet

哈希表条目上限由参数net.netfilter.nf_conntrack_max设置。

网上文章对这个问题的解决方法往往是调大该参数。但在涉及多个network namespace的场景下，不能简单的这样做，还是要根据自身场景分析清楚具体原因。

根据CentOS7 3.10.0-957版本内核源码，实际上每个network namespace的conntrack哈希表是独立的。在表示network namespace的结构体net中的成员ct表示conntrack相关信息:

struct net {
    ...
    struct netns_ct     ct;
    ...
}

netns_ct结构中保存有独立的哈希表相关信息:

struct netns_ct {
    atomic_t        count;
    ...
    unsigned int        htable_size;
    RH_KABI_DEPRECATE(seqcount_t, generation)
    struct kmem_cache   *nf_conntrack_cachep;
    struct hlist_nulls_head *hash;
    ...
}

阅读全文 »

关于/etc/sysctl.conf生效时机

发表于 2025-02-08 更新于 2026-01-04 分类于 Kernel

Linux内核提供了sysctl机制用于动态配置内核及内核模块的参数, 每个参数对应/proc/sys/下的一个文件，可以通过sysctl命令或直接操作/proc/sys/下的文件对参数进行读写。比如，net.ipv4.ip_forward对应文件/proc/sys/net/ipv4/ip_forward。sysctl命令实际是是对/proc/sys/操作的封装。

如果需要将sysctl参数持久化，可以将参数写入文件/etc/sysctl.conf文件中，这样参数在系统重启后依然生效。这是如何实现的呢？实际是由systemd-sysctl(或其他类似功能的服务)在系统完成内核模块的加载后，再来加载/etc/sysctl.conf里的参数。

如果需要立即生效/etc/sysctl.conf中的参数，可以执行sysctl -p。但如果此时内核模块未并加载，由于/proc/sys/目录下并不存在对应的参数文件，因而执行会失败。尽管这种场景下sysctl -p执行失败，但通过modprobe命令加载内核模块完成后，查看对应的sysctl参数，却发现sysctl参数已经生效。那这种场景下是如何令/etc/sysctl.conf中的参数生效的呢？

阅读全文 »

多线程程序设置CURLOPT_NOSIGNAL选项

发表于 2025-01-21 更新于 2026-01-04 分类于 MISC

近期遇到一个C++程序退出的问题，经过调查发现，程序是由于接收到SIGPIPE信号而退出。该程序是多线程程序，使用libcurl进行HTTPS访问，同时设置了CURLOPT_NOSIGNAL选项，但没有自己处理SIGPIPE信号。在一些情况下，连接已经处理关闭状态，但应用程序不知道，依然向连接发送数据，就会导致SIGPIPE信号产生，进而导致程序退出。修复方法比较简单，只要应用程序设置SIGPIPE信号的处理程序即可。

上述问题要发生的一个前提是CURLOPT_NOSIGNAL选项需要被设置，什么情况下需要设置它呢？libcurl的作者的博文上写到过这个问题:

https://daniel.haxx.se/blog/2021/09/27/common-mistakes-when-using-libcurl/

12. Understanding CURLOPT_NOSIGNAL
Signals is a Unix concept where an asynchronous notification is sent to a process or to a specific thread within the same process in order to notify it of an event that occurred.

What does libcurl use signals for?
When using the synchronous name resolver, libcurl uses alarm() to abort slow name resolves (if a timeout is set), which ultimately sends a SIGALARM to the process and is caught by libcurl

By default, libcurl installs its own sighandler while running, and restores the original one again on return – for SIGALARM and SIGPIPE.

Closing TLS (with OpenSSL etc) can trigger a SIGPIPE if the connection is dead.

Unless CURLOPT_NOSIGNAL is set! (default)

What does CURLOPT_NOSIGNAL do?
It prevents libcurl from triggering signals

When disabled, it prevents libcurl from installing its own sighandler and…

Generated signals must then be handled by the libcurl-using application itself

阅读全文 »