我正在一个内核5.10.50的定制嵌入式Linux设备上运行SystemD版本的249.7+。我使用Podman 4.0.2与Docker一起运行几个容器。我遇到的问题是,podman系统服务中的“conmon”子进程重复了坞-组合进程生成的每个日志日志条目。我希望删除日志条目的conmon版本,并且只保留那些由生成的日志条目。
Journalctl显示的重复条目如下:
-- Journal begins at Sun 2012-01-01 00:02:21 UTC. --
Mar 30 17:06:15 device conmon[1625]: {"products":["Linux","Windows","Mac"]}
Mar 30 17:06:16 device sh[16648]: app1 | App1 endpoint hit ...
Mar 30 17:06:16 device sh[16648]: app3 | {"products":["Linux","Windows","Mac"]}
Mar 30 17:06:16 device sh[16648]: app2 | App2 endpoint hit ...
Mar 30 17:06:16 device sh[16648]: app1 | 10.89.0.3 - - [30/Mar/2022 17:06:15] "GET / HTTP/1.1" 200 -
Mar 30 17:06:16 device sh[16648]: app2 | Getting http://app1 ...
Mar 30 17:06:16 device sh[16648]: app2 | Status of GET: 200
Mar 30 17:06:16 device sh[16648]: app2 | Results of GET: {"products":["Linux","Windows","Mac"]}
Mar 30 17:06:16 device sh[16648]: app2 |
Mar 30 17:06:16 device sh[16648]: app2 | 10.89.0.4 - - [30/Mar/2022 17:06:15] "GET / HTTP/1.1" 200 -
Mar 30 17:06:21 device conmon[1558]: App2 endpoint hit ...
Mar 30 17:06:21 device conmon[1558]: Getting http://app1 ...
Mar 30 17:06:22 device sh[16648]: app1 | App1 endpoint hit ...
Mar 30 17:06:22 device sh[16648]: app2 | App2 endpoint hit ...
Mar 30 17:06:22 device sh[16648]: app1 | 10.89.0.3 - - [30/Mar/2022 17:06:22] "GET / HTTP/1.1" 200 -
Mar 30 17:06:22 device sh[16648]: app3 | {"products":["Linux","Windows","Mac"]}
Mar 30 17:06:22 device sh[16648]: app2 | Getting http://app1 ...
Mar 30 17:06:22 device sh[16648]: app2 | Status of GET: 200
Mar 30 17:06:22 device sh[16648]: app2 | Results of GET: {"products":["Linux","Windows","Mac"]}
Mar 30 17:06:22 device sh[16648]: app2 |
Mar 30 17:06:22 device sh[16648]: app2 | 10.89.0.4 - - [30/Mar/2022 17:06:22] "GET / HTTP/1.1" 200 -
Mar 30 17:06:22 device conmon[1393]: App1 endpoint hit ...
Mar 30 17:06:22 device conmon[1393]:
Mar 30 17:06:22 device conmon[1393]: 10.89.0.3 - - [30/Mar/2022 17:06:22] "GET / HTTP/1.1" 200 -
Mar 30 17:06:22 device conmon[1558]: Status of GET: 200
Mar 30 17:06:22 device conmon[1558]:
Mar 30 17:06:22 device conmon[1558]: Results of GET: {"products":["Linux","Windows","Mac"]}
Mar 30 17:06:22 device conmon[1558]:
Mar 30 17:06:22 device conmon[1558]: 10.89.0.4 - - [30/Mar/2022 17:06:22] "GET / HTTP/1.1" 200 -
Mar 30 17:06:22 device conmon[1625]: {"products":["Linux","Windows","Mac"]}conmon日志由podman.service的“conmon”子进程生成。
root@device:~# systemctl status podman
● podman.service - Podman API Service
Loaded: loaded (8;;file://device/lib/systemd/system/podman.service^G/lib/systemd/system/podman.service8;;^G; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-03-30 15:48:55 UTC; 1h 18min ago
TriggeredBy: ● podman.socket
Docs: 8;;man:podman-system-service(1)^Gman:podman-system-service(1)8;;^G
Main PID: 515 (podman)
Tasks: 17 (limit: 495)
Memory: 11.8M
CPU: 2min 11.029s
CGroup: /system.slice/podman.service
├─ 515 /usr/bin/podman --log-level=error system service --time=0
├─1391 /usr/bin/dnsmasq -u root --conf-file=/run/containers/cni/dnsname/docker-compose_host_internal_net/dnsmasq.conf
├─1393 /usr/bin/conmon --api-version 1 -c 6739cff6019d2f7e8f123d6fb02f163ec99ee73d322672c41d81f85d6218c66f -u 6739cff6019d2f7e8f123d6fb02f163ec99ee73d322672c41d81f85d6218c66f -r /usr/bin/crun -b /con>
├─1558 /usr/bin/conmon --api-version 1 -c ae34f69196a5d1b332f2f137942d3728c24bb41d06392b13dcfc7296f39b7936 -u ae34f69196a5d1b332f2f137942d3728c24bb41d06392b13dcfc7296f39b7936 -r /usr/bin/crun -b /con>
└─1625 /usr/bin/conmon --api-version 1 -c b94e032b37a8690f847442ab9cdcf7b78aefab45231098d02c60b5f79e5c3474 -u b94e032b37a8690f847442ab9cdcf7b78aefab45231098d02c60b5f79e5c3474 -r /usr/bin/crun -b /con>
Mar 30 17:07:19 device conmon[1558]: App2 endpoint hit ...
Mar 30 17:07:19 device conmon[1558]: Getting http://app1 ...
Mar 30 17:07:20 device conmon[1393]: App1 endpoint hit ...
Mar 30 17:07:20 device conmon[1393]: 10.89.0.3 - - [30/Mar/2022 17:07:20] "GET / HTTP/1.1" 200 -
Mar 30 17:07:20 device conmon[1558]: Status of GET: 200
Mar 30 17:07:20 device conmon[1558]:
Mar 30 17:07:20 device conmon[1558]: Results of GET: {"products":["Linux","Windows","Mac"]}
Mar 30 17:07:20 device conmon[1558]:
Mar 30 17:07:20 device conmon[1558]: 10.89.0.4 - - [30/Mar/2022 17:07:20] "GET / HTTP/1.1" 200 -
Mar 30 17:07:20 device conmon[1625]: {"products":["Linux","Windows","Mac"]}我已经尝试将podman.service StandardOutput和SystemD服务文件中的StandardErr重定向为null -但是conmon日志仍然显示在SystemD the中。
root@device:~# cat /lib/systemd/system/podman.service
[Unit]
Description=Podman API Service
Requires=podman.socket
After=podman.socket
Documentation=man:podman-system-service(1)
StartLimitIntervalSec=0
[Service]
Environment=XDG_RUNTIME_DIR=
CPUWeight=1000
Type=exec
KillMode=process
StandardOutput=null
StandardError=null
Environment=LOGGING="--log-level=error"
#ExecStart=/bin/sh -c "/usr/bin/podman $LOGGING system service --time=0 1>/dev/null 2>/dev/null"
ExecStart=/usr/bin/podman $LOGGING system service --time=0我怎样才能摆脱召集日志条目?谢谢。
发布于 2022-04-03 21:00:50
尝试LogLevelMax=error,它只是将单元的所有日志记录限制为日志级别错误或更糟。至少对我来说,这解决了一个类似的问题:一个程序会用垃圾邮件发送日志。也许在这种情况下,它也会有所帮助,至少在某种意义上,它会抑制来自子进程的所有非错误消息。
这是相当自我解释的,但更多的细节,请查看手册中的systemd单位,它解释了这到底是做什么:https://www.freedesktop.org/software/systemd/man/systemd.exec.html。
https://unix.stackexchange.com/questions/697389
复制相似问题