Eu me lembro das vezes em que provavelmente literalmente todas as mensagens de log estavam sendo colocadas em /var/log/messages e /var/log/syslog . Foi no ano 2000, se alguém está curioso. Agora é diferente. Os arquivos de log devem estar em ordem, mas eles não possuem entradas. Na minha percepção, 90% das situações problemáticas são apenas silenciosas, não há como encontrar nada em /var/log arquivos.
Como ter /var/log/messages de volta e tê-lo realmente detalhado?
PS. Como exemplo. Quando eu instalo o vsftpd e faço:
sudo restart vsftpd
então o que entra no syslog é a seguinte linha:
kernel: [ 7167.143648] init: vsftpd main process (5823) killed by TERM signal
Esse é o único efeito de reiniciar um servidor FTP. Pense nisso - é possível que o vsftpd não produza nenhum banner na inicialização? É difícil acreditar em mim.
Além disso, o log vem do kernel , é o dmesg que está capturando isso. Isso é ridículo. Se o kernel não capturar o sinal TERM, não haverá nenhum rastreio nos logs sobre o reinício do daemon FTP . Este é o caso quando proftpd é reiniciado via /etc/init.d/proftpd . Nenhum rastreio nos logs, exceto /var/log/proftpd/proftpd.log , que é o próprio arquivo de log de proftpd configurado pela opção SystemLog .
PS2 : Eu atribuo resultados do Virtual Linux, provavelmente o primeiro live CD criado, baseado no Mandrake, do ano 2001 (kernel 2.4.3-20mdk). Reiniciar o proftpd rende lá (em /var/log/messages ):
proftpd[2699]: ProFTPD killed (signal 15)
proftpd[2699]: ProFTPD 1.2.2rc1 standalone mode SHUTDOWN
proftpd: proftpd shutdown succeeded
proftpd[2730]: ProFTPD 1.2.2rc1 (release) (built Sun Apr 8 09:53:35 CEST 2001) standalone mode STARTUP
proftpd: proftpd startup succeeded
Em 14,04%, osyslog está vazio e o seguinte é registrado em proftpd.log .
proftpd[1326] asus-1201N: ProFTPD killed (signal 15)
proftpd[1326] asus-1201N: ProFTPD 1.3.5rc3 standalone mode SHUTDOWN
proftpd[2620] asus-1201N: ProFTPD 1.3.5rc3 (devel) (built Fri Dec 20 2013 18:04:47 UTC) standalone mode STARTUP
No VLinux, o seguinte é registrado em messages quando sshd é reiniciado:
sshd[2821]: Received signal 15; terminating
sshd: sshd shutdown succeeded
sshd[2924]: Server listening on 0.0.0.0 port 22.
sshd[2924]: Generating 768 bit RSA key.
sshd: sshd startup succeeded
sshd[2924]: RSA key generation complete
Em 14,04%, osyslog está vazio e o seguinte é registrado em auth.log (por quê?):
Nov 28 09:11:22 asus-1201N sshd[2500]: Received signal 15; terminating.
Nov 28 09:11:22 asus-1201N sshd[2634]: Server listening on 0.0.0.0 port 22.
Nov 28 09:11:22 asus-1201N sshd[2634]: Server listening on :: port 22.
Então, basicamente, duas linhas quando não contando a terceira linha IPv6. Em seguida, introduzi um erro em sshd_config e repeti as reinicializações. VLinux / messages:
sshd[2924]: Received signal 15; terminating.
sshd: sshd shutdown succeeded
sshd: sshd startup failed
Em 14.04, desta vez, auth.log está vazio e syslog não está:
kernel: [ 2905.854777] init: ssh main process (2718) terminated with status 255
kernel: [ 2905.854836] init: ssh main process ended, respawning
No VLinux há uma mensagem detalhada sobre erro no arquivo de configuração impresso no console no qual eu emito /etc/init.d/sshd restart ("Bad configuration option: ..."). Gostaria de saber se quando sshd seria iniciado pelo sistema, a mensagem seria registrada em messages . Meu palpite é sim, mas não posso testar isso com o CD ao vivo.
Reiniciando o proftpd com erro na configuração completa dos logs de informações no VLinux e no 14.04 gera mensagem de erro no terminal quando feito pela segunda vez, e nada além de "SHUTDOWN" está logado em proftpd.log ( syslog está vazio).
Resumo:
- Eu não pude provar claramente que
messages tinha mais informações, no entanto, pode ser visto que o que prevalece agora é economizar espaço em disco (?) e não registrar muito
- é preciso saltar entre
auth.log , syslog e logs dedicados para encontrar alguma informação, e é principalmente um conteúdo sem sentido, pois aparentemente nenhuma saída dos daemons é encaminhada para os logs e, em vez disso, é o kernel que captura "alguma coisa" ou daemon próprio trabalho para gerenciar o próprio arquivo de log
- Tenho certeza de que no caso de algum erro sofisticado eu encontraria algo em
messages , enquanto no atual syslog haveria informações típicas do kernel sobre o término de um processo ou algo assim; Eu ainda poderia ter uma idéia de tal teste para mostrar isso
- embora eu não tenha mostrado claramente que o registro atual está perdendo as coisas, com certeza mostrei como o
messages era detalhado