Editar 2016-06-02
Se você estiver tentando encontrar "Mensagens de log do Upstart" em geral, verifique /var/log/upstart/ . É aí que o Upstart salva stdout e stderr dos serviços do Upstart. Graças a resposta de leopd para apontar isso.
Se você está procurando por mensagens de log do próprio Upstart, que são configuradas por initctl log-priority e emitidas por initctl emit , continue lendo!
Versão curta
As entradas de log devem realmente aparecer no dmesg. Apesar disso, eles não aparecem por padrão em /var/log .
Se você quiser também /var/log , adicione $KLogPermitNonKernelFacility on à configuração do rsyslogd. Eu sugiro criar um arquivo personalizado como /etc/rsyslog.d/60-custom.conf para evitar a edição /etc/rsyslog.conf , já que é gerenciado pelo dpkg. Agora, as mensagens do Upstart devem aparecer em /var/log/syslog , assim que você definir o log-priority para info do Upstart ou mais.
Versão longa
Isso me levou dias para rastrear, mas aparentemente o Upstart (1.5) não registra no syslog, ou seja, ele 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 achei que fosse possível para que os processos de espaço do usuário gravassem naquele buffer, mas aparentemente eles podem gravar em /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 escritas no buffer de anel do kernel são automaticamente copiadas para o syslog pelo kernel (pelo menos é o que eu sempre achei). Acontece que isso é realmente feito por um daemon de espaço do usuário, tradicionalmente 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 de anel do kernel a partir do espaço do usuário realmente parecem diferentes das mensagens escritas do espaço do kernel: elas possuem um recurso diferente. O dmesg tem algumas opções que interagem com isto: -x mostrará o recurso (e a prioridade), enquanto -u e -k dizem ao dmesg para mostrar apenas mensagens de facilidade do usuário e mensagens do recurso do kernel, respectivamente.
Agora aqui está o argumento: por padrão, o rsyslogd ignora mensagens com um recurso não-kernel quando está lendo 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ê desejar que o rsyslogd processe essas mensagens. Note que o resto da configuração do rsyslogd tratará todas as mensagens do buffer de anel do kernel como tendo o recurso kern , independente do recurso que elas tivessem 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 gravam em /dev/log . O código pode ler do syslog lendo /dev/log , e é isso que o syslogd e suas substituições fazem. rsyslogd lê /dev/log usando seu módulo de entrada imuxsock .
Buffer de anel do kernel
O espaço do kernel grava neste buffer chamando a função do kernel printk() , então às vezes é chamado de buffer do printk. O espaço do usuário pode gravar escrevendo para /dev/kmsg . O espaço do usuário pode ler esse buffer por vários métodos: ele pode ler /proc/kmsg (o que o dmesg faz por padrão) ou ler /dev/kmsg ou chamar o sistema syslog() , que é descrito em man 2 syslog e é completamente diferente da função glibc syslog() descrita em man 3 syslog . A glibc na verdade fornece um wrapper para a chamada do sistema syslog() , chamada klogctl() , para ajudar a aliviar essa confusão.
Tradicionalmente, klogd lê uma dessas interfaces e, em seguida, chama a função glibc syslog() para copiá-las para o syslog. O rsyslogd lê uma dessas interfaces através de seu módulo de entrada imklog , mas o AFAIK não se incomoda em chamar o glibc syslog() , e é por isso que ele não é exatamente como o klogd; ele apenas processa a saída de imklog da mesma forma que processa a saída de qualquer outro módulo de entrada. Há a ressalva adicional de que todo imklog output possui o recurso kern , independentemente das mensagens do recurso no buffer de anel do kernel.