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?
Resumindo, carregue sua biblioteca por
LD_PRELOADoverride syslog(3) em vez de connect(3).O
/dev/logsoquete Unix é usado pela função glibc syslog(3), que se conecta a ele e grava nele. Sobrescrever connect(3) provavelmente não funciona porque a implementação do syslog(3) dentro da glibc irá executar a chamada do sistema connect(2) ao invés da função de biblioteca, então umLD_PRELOADgancho não irá interceptar a chamada de dentro do syslog(3).Há uma desconexão entre
strace, que mostra syscalls, eLD_PRELOAD, que pode substituir funções de biblioteca (neste caso, funções de glibc.) O fato de haver uma função connect(3) glibc e também uma chamada de sistema connect(2) também ajuda com essa confusão. (É possível que o usoltracetenha ajudado aqui, mostrando chamadas para syslog(3).)Você provavelmente pode confirmar que substituir connect(3)
LD_PRELOADcomo você está fazendo não funcionará com syslog(3) fazendo com que seu programa de teste chame syslog(3) diretamente em vez de se conectar explicitamente a/dev/log, o que eu suspeito que seja como o .NET O aplicativo principal está se comportando.Conectar-se ao syslog(3) também é potencialmente mais útil, pois estando em um nível mais alto na pilha, você pode usar esse gancho para tomar decisões como encaminhar seletivamente algumas das mensagens para o syslog. (Você pode carregar a função syslog de glibc com
dlsym(RTLD_NEXT, "syslog"), e então você pode usar esse ponteiro de função para chamar syslog(3) para as mensagens que você deseja encaminhar do seu gancho.)A abordagem de substituir
/dev/logpor um link simbólico para/dev/nullé falha, pois/dev/nullnão aceitará uma operação connect(2) (somente operações de arquivo como open(2)), então o syslog(3) tentará se conectar e obterá um erro e de alguma forma tentará lidar com isso (ou talvez devolvê-lo ao chamador), em qualquer caso, isso pode ter efeitos colaterais.Espero que usar uma
LD_PRELOADsubstituição de syslog(3) seja tudo o que você precisa aqui.