init, syslog e stdout / stderr

Question

Estou tentando construir um sistema embarcado com o linux. (Significa muito poucos recursos e não muito mais do que o busybox.) Eu gostaria de ter certeza de que tudo está indo para o syslog. Estou usando a versão mais recente do busybox (v.1.21.1), com o init incorporado e o syslogd.

Há alguns problemas, no entanto. Primeiro o inittab:

....
null::sysinit:/bin/sh /etc/rc
null::sysinit:/bin/touch /var/log/messages
null::respawn:/sbin/syslogd -n -S -s 12 -b 8
null::respawn:/sbin/klogd -n
....

O script rc é executado antes do syslog, o que significa que todas as informações úteis do rc são perdidas. (Eu não tenho certeza, o que o comando touch é para btw.) Eu poderia iniciar o syslog antes de rc (null :: sysinit: / sbin / syslogd ...), mas isso removeria o importantíssimo "respawn".

Além disso, quando daemons de terceiros estão começando, pode ser assim:

...
null::respawn:/bin/modbus
...

Se o daemon não suportar syslog ou se algo escorregar (por exemplo, uma impressão para stderr), ele será perdido. Não consigo redirecionar a saída para o syslog. Por exemplo.

...
console::respawn:/bin/modbus|logger 2>1
...

Eu tentei várias combinações diferentes. Nada parece funcionar bem. Ofc, eu poderia editar todos os daemons e fazê-los suportar o syslog. (Mas e se algo escorregar?) Isso poderia ser resolvido se eu pudesse escrever algo assim:

log::respawn:/bin/modbus

E, na verdade, existe um / dev / log. Mas é um soquete, redirecionamentos normais não funcionam. ... então eu poderia fazê-lo funcionar através de um módulo de kernel personalizado. Por exemplo. Eu poderia criar um módulo que cria um / dev / syslog_link que escreve tudo no printk. O problema é que o syslog marcaria todas as mensagens daquele como 'kernel'. Muito errado.

Então, agora estou pensando que poderia criar um módulo do kernel que grava no / dev / log: link link

Eu não sei se é possível e escrever em arquivos do espaço do kernel prejudica meu frágil sentido de certo e errado.

Alguma opinião?

    

Answer 1

The rc script is run before syslog

Pode haver uma boa razão para isso, por exemplo, porque é aí que o sistema de arquivos que contém /var/log é remontado como rw. Se não, então você pode iniciar o syslog primeiro.

I've tried a number of different combinations. Nothing seems to work well.

Eu não joguei muito com o inittab em mais de alguns anos. Você tentou colocar, por exemplo, /bin/modbus|logger 2>1 em um script curto e depois usar isso com respawn ?

Ofc, I could edit all the daemons and make them support syslog.

Se você puder, você provavelmente deveria. Ou você pode fazer com que eles gravem diretamente em um arquivo.

there is a /dev/log. But it's a socket, normal redirects won't work. ... so I could make it work through a custom kernel module.

Isso parece um exagero. Seria mais fácil usar um daemon do userspace e iniciá-lo primeiro; pode ler de um fifo e escrever para qualquer coisa. Claro, isso pode ser um pouco redundante considerando que já existe syslog: / O truque com um leitor fifo é reabrir o pipe quando read() retornar 0. Mas, novamente, eu tentaria fazer o syslog funcionar primeiro. Manter o material padrão parece mais simples.

    

Answer 2

Você pode considerar / dev / kmsg, para mensagens de inicialização antecipadas. Estes serão mantidos em um buffer circular no kernel até que o userspace (de praticamente todas as distribuições) faça o dump no syslog depois que o sistema de arquivos for tornado gravável e as verificações de disco forem executadas. Isso funcionará desde que o seu buffer do kernel seja maior que o tamanho das mensagens que acontecem antes do logger ser iniciado. O tamanho do buffer de log do kernel é configurável em tempo de compilação. Você deve ser capaz de redirecionar as coisas para / dev / kmsg com scripts de shell típicos.

Quanto a redirecionar o stdout de programas arbitrários para o syslog, existem utilitários que lêem STDIN e redirecionam para o syslog, e então você canaliza a saída do daemon para o utilitário. Aqui está uma que eu achei útil: link

Tudo isso dito, há muitas pessoas fazendo muitas coisas inteligentes com o registro. Desde que você parece interessado no assunto, você pode estar interessado em ler a seção "O design do syslog é falho do início" de link

Espero que ajude.