No Ubuntu 12.04, posso encontrar mensagens de log do Upstart /var/log/syslog.

Comandos:

# initctl log-priority info
# initctl emit hello

Registro:

Apr  1 01:56:56 precise64 kernel: [ 8365.820425] init: Connection from private client
Apr  1 01:56:56 precise64 kernel: [ 8365.821130] init: Handling hello event

No Ubuntu 13.10, as mensagens não aparecem no diretório syslogou em nenhum outro lugar /var/log, embora comandos logger hellocomo o esperado. Eu deveria procurá-los em outro lugar? Existe uma configuração que eu precise alterar em algum lugar?

Há uma pergunta sobre falha no servidor de alguém que parece estar tendo o mesmo problema no Ubuntu 13.04, e mais aqui e aqui que também podem estar descrevendo o mesmo problema. Infelizmente, essas perguntas não oferecem pistas para o problema.

Editar 02/06/2016

Se você estiver tentando encontrar "Mensagens de registro iniciais" em geral, verifique /var/log/upstart/. É aí que o Upstart salva stdoute stderrdos serviços do Upstart. Obrigado à resposta de leopd por apontar isso.

Se você estiver procurando mensagens de log do próprio Upstart, configuradas initctl log-prioritye emitidas por initctl emit, continue lendo!

Versão curta

As entradas do log devem realmente aparecer no dmesg. Apesar disso, eles não aparecem por padrão no /var/log.

Se você também quiser /var/log, adicione $KLogPermitNonKernelFacility onà configuração do rsyslogd. Sugiro a criação de um arquivo personalizado /etc/rsyslog.d/60-custom.confpara evitar a edição /etc/rsyslog.conf, pois é gerenciado pelo dpkg. Agora, as mensagens do Upstart devem aparecer /var/log/syslog, assim que você definir o Upstart log-prioritycomo infoou não.

Versão longa

Levei dias para rastrear, mas aparentemente o Upstart (1.5) não registra no syslog, ou seja, não chama a função glibc syslog(). Em vez disso, o Upstart registra no buffer de anel do kernel, que é o que o dmesg lê. Agora, eu não achava que era possível que os processos de espaço do usuário gravassem nesse buffer, mas aparentemente eles podem escrever /dev/kmsg, e é exatamente isso que o Upstart faz. Então essa é a primeira parte do quebra-cabeça.

A segunda parte é que existe uma crença generalizada de que as mensagens gravadas no buffer de anel do kernel são automaticamente copiadas para o syslog pelo kernel (pelo menos é o que eu sempre pensei). Acontece que isso é realmente feito por um daemon de espaço do usuário, tradicionalmente o klogd, que opera em conjunto com o syslogd. Obviamente, o rsyslogd substitui o syslogd, mas aparentemente ele também substitui o klogd (mais ou menos: veja as notas no final).

A terceira parte é que as mensagens gravadas no buffer do anel do kernel do espaço do usuário realmente parecem diferentes das mensagens gravadas do espaço do kernel: elas têm um recurso diferente. dmesg tem algumas opções que interagem com este: -xvai mostrar a facilidade (e a prioridade), enquanto -ue -kcontam dmesg para mostrar apenas mensagens de instalações de usuário e mensagens de instalações kernel, respectivamente.

Agora, aqui está o argumento decisivo: por padrão, o rsyslogd ignora as mensagens com um recurso que não seja do kernel ao ler mensagens do buffer de anel do kernel. A opção de configuração relevante é $KLogPermitNonKernelFacility, que está desativada por padrão e precisa ser ativada se você quiser que o rsyslogd processe essas mensagens. Observe que o restante da configuração do rsyslogd tratará todas as mensagens do buffer de anel do kernel como tendo o kernrecurso, independentemente do recurso que eles tinham no buffer de anel do kernel.

Mais Informações

syslog

O código pode gravar no syslog chamando a função glibc syslog(), descrita em man 3 syslog. Aparentemente, essas funções escrevem para /dev/log. O código pode ler do syslog lendo /dev/log, e é isso que syslogde suas substituições fazem. rsyslogdlê /dev/logusando seu imuxsockmódulo de entrada.

Buffer de anel do kernel

O espaço do kernel grava nesse buffer chamando a função kernel printk(), então às vezes é chamado de buffer printk. O espaço do usuário pode gravar nele, escrevendo para /dev/kmsg. O espaço do usuário pode ler desse buffer por vários métodos: ele pode ler /proc/kmsg(o que o dmesg faz por padrão), ou pode ler /dev/kmsgou pode chamar a chamada do sistema syslog(), descrita em man 2 sysloge completamente diferente da função glibc syslog()descrita no man 3 syslog. O glibc realmente fornece um invólucro para a chamada do sistema syslog(), chamada klogctl(), para ajudar a aliviar essa confusão.

Tradicionalmente, klogdlê de uma dessas interfaces e chama a função glibc syslog()para copiá-las para o syslog. O rsyslogd lê uma dessas interfaces através de seu imklogmódulo de entrada, mas o AFAIK não se incomoda em chamar a glibc syslog(), e é por isso que não é exatamente como o klogd; apenas processa a saída, imklogassim como processa a saída de qualquer outro módulo de entrada. Há a ressalva adicional de que toda imklogsaída tem kernfacilidade, independentemente das mensagens da instalação no buffer de anel do kernel.

Referências

• http://upstart.ubuntu.com/cookbook/#initctl-log-priority ( Indica incorretamente que o Upstart registra no syslog)
• https://www.kernel.org/doc/Documentation/ABI/testing/dev-kmsg
• http://www.gnu.org/software/libc/manual/html_node/Overview-of-Syslog.html
• http://www.rsyslog.com/doc/v5-stable/configuration/modules/imklog.html (Observe que isso é para a v5, usada no Ubuntu 12.04. Essas opções são consideradas herdadas nas versões recentes do rsyslog)

Eu encontrei o meu /var/log/upstart/