Início / unix / Perguntas / 697389
Accepted
PhilBot
Asked: 2022-03-31 09:26:41 +0800 CST

SystemD JournalD não pode desabilitar a saída do processo filho

  • 772

Estou executando o SystemD versão 249.7+ em um dispositivo Linux incorporado personalizado com Kernel 5.10.50. Estou usando o Podman 4.0.2 com Docker-Compose para executar alguns contêineres. O problema que tenho é que os processos filho 'conmon' do serviço de sistema podman duplicam cada entrada de log journald que o processo de composição do docker produz. Eu quero remover a versão comum das entradas de log e manter apenas aquelas produzidas pelo docker-compose.

Journalctl mostra as entradas duplicadas assim:

-- 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"]}

Os logs comuns são produzidos pelos processos filho 'conmon' do podman.service.

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"]}

Eu tentei redirecionar o podman.service StandardOutput e StandardErr no arquivo de serviço SystemD para null - mas os logs comuns ainda aparecem com journalctl.

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

Como posso me livrar das entradas de log comuns? Obrigado.

systemd systemctl

1 respostas

  1. Best Answer

    Try LogLevelMax=error, que simplesmente limita todos os logs da unidade para registrar erro de nível ou pior. Pelo menos para mim, isso resolveu um problema semelhante em que um programa enviaria spam ao journalctl com mensagens. Talvez também ajude neste caso, pelo menos no sentido de que suprimiria todas as mensagens sem erro dos processos filhos.

    É bastante autoexplicativo, mas para mais detalhes, verifique o manual de unidades systemd, ele explica o que isso faz exatamente: https://www.freedesktop.org/software/systemd/man/systemd.exec.html

    • 1

relate perguntas