Estou usando um aplicativo .NET Core de terceiros (uma distribuição binária usada por uma extensão do VS Code) que infelizmente tem o log de diagnóstico habilitado sem nenhuma maneira aparente de desabilitá-lo (já relatei isso aos autores). A solução ideal (além de poder desativá-lo) seria se eu pudesse especificar ao systemd que ele não deveria registrar nada para esse programa em particular, mas não consegui encontrar nenhuma maneira de fazê-lo. Aqui está tudo o que tentei até agora:
A primeira coisa que tentei foi redirecionar stdoute stderrpara /dev/null: dotnet-app > /dev/null 2>&1. Isso realmente desativou qualquer saída normal, mas o log de diagnóstico ainda estava sendo gravado no diário do systemd.
Eu esperava que o aplicativo tivesse um argumento de linha de comando que me permitisse desabilitar o log de diagnóstico. Ele tinha um argumento de verbosidade, mas depois de experimentar, ele só parecia ter efeito na saída normal, não no log de diagnóstico.
Ao usar stracee procurar chamadas para connect, descobri que o aplicativo escrevia o log de diagnóstico diretamente para /dev/log.
O caminho /dev/logé um link simbólico para /run/systemd/journal/dev-log, portanto, para verificar minha descoberta, alterei o link simbólico para apontar para /dev/null. Isso realmente impediu que o log de diagnóstico aparecesse no diário do systemd.
Fui informado LD_PRELOADe fiz uma biblioteca que substituiu o padrão connectpela minha própria versão que retornou um erro no caso de tentar se conectar ao /dev/log. Isso funcionou corretamente no meu programa de teste, mas falhou com o aplicativo .NET Core, falhando com o connect ENOENT /tmp/CoreFxPipe_1ddf2df2725f40a68990c92cb4d1ff1e. Eu experimentei com minha biblioteca, mas mesmo que tudo que eu fizesse fosse passar diretamente os argumentos para a connectfunção padrão, ela ainda falharia com o mesmo erro.
Em seguida, tentei usar namespaces do Linux para fazer com que /dev/logapontasse /dev/nullapenas para o aplicativo .NET Core: unshare --map-root-user --mount sh -c "mount --bind /dev/null /dev/log; dotnet-app $@". Isso também falhou com o mesmo erro, embora tenha funcionado novamente para o meu programa de teste. Mesmo apenas usando unshare --map-root-user --mount dotnet-app "$@"falharia com o erro.
Em seguida, tentei usar gdbpara fechar o descritor de arquivo /dev/logenquanto o aplicativo estava em execução. Isso funcionou, mas reabre depois de algum tempo. Também tentei alterar o descritor de arquivo para apontar para /dev/null, que também funcionou, mas também foi redefinido para /dev/logdepois de algum tempo.
Minha última tentativa foi escrever meu próprio soquete UNIX que filtraria todos os escritos nele pelo aplicativo .NET Core. Isso realmente funcionou, mas eu aprendi que o PID é enviado junto com o que está escrito nos soquetes UNIX, então tudo passado para o diário do systemd reportaria vindo do PID do programa que suporta meu soquete UNIX.
Por enquanto esta é uma solução aceitável para mim, porque no meu sistema quase nada usa /dev/log, mas eu gostaria de uma solução melhor. Por exemplo, li que era possível falsificar certas coisas como root para soquetes UNIX , mas não consegui descobrir mais sobre isso.
Ou se alguém tiver alguma ideia sobre por que ambos LD_PRELOADe unsharepode falhar para o aplicativo .NET Core, enquanto eles funcionam bem para um programa de teste C simples que grava em /dev/log?