¿Dónde están los mensajes de registro de Upstart en Ubuntu 13.X?

28

En Ubuntu 12.04, puedo encontrar mensajes de registro de Upstart en /var/log/syslog.

Comandos:

# initctl log-priority info
# initctl emit hello

Iniciar sesión:

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

En Ubuntu 13.10, los mensajes no aparecen en syslogel /var/logdirectorio ni en ningún otro lugar , aunque los comandos logger hellofuncionan como se espera. ¿Debería estar buscándolos en otro lugar? ¿Hay alguna configuración que deba cambiar en alguna parte?

Hay una pregunta sobre Server Fault de alguien que parece estar teniendo el mismo problema en Ubuntu 13.04, y más aquí y aquí que también puede estar describiendo el mismo problema. Desafortunadamente, estas preguntas no ofrecen pistas para el problema.

Bradd Szonye
fuente

Respuestas:

39

Editar 2016-06-02

Si está intentando encontrar "Mensajes de registro de inicio" en general, verifique /var/log/upstart/. Ahí es donde ahorra Upstart stdouty stderrde los servicios de Upstart. Gracias a la respuesta de leopd por señalar esto.

Si está buscando mensajes de registro de Upstart, configurados initctl log-priorityy emitidos por initctl emit, ¡siga leyendo!

Version corta

Las entradas de registro deberían aparecer en dmesg. A pesar de eso, no aparecen por defecto en /var/log.

Si también los quieres /var/log, $KLogPermitNonKernelFacility onagrégalos a la configuración de rsyslogd. Sugiero crear un archivo personalizado /etc/rsyslog.d/60-custom.confpara evitar la edición /etc/rsyslog.conf, ya que es administrado por dpkg. Ahora los mensajes de Upstart deberían aparecer en /var/log/syslog, una vez que configure Upstart log-priorityen más infoo menos.

Versión larga

Esto me llevó días localizarlo, pero aparentemente Upstart (1.5) no se registra en syslog, es decir, no llama a la función glibc syslog(). En cambio, Upstart se registra en el búfer de anillo del núcleo, que es lo que lee dmesg. Ahora, no pensé que fuera posible que los procesos de espacio de usuario escribieran en ese búfer, pero aparentemente pueden hacerlo escribiendo a /dev/kmsgeso, y eso es exactamente lo que hace Upstart. Esa es la primera parte del rompecabezas.

La segunda parte es que existe una creencia generalizada de que los mensajes escritos en el búfer de anillo del núcleo se copian automáticamente en el registro del sistema (al menos eso es lo que siempre pensé). Resulta que esto lo hace un demonio espacial de usuario, tradicionalmente klogd, que opera en conjunto con syslogd. Obviamente, rsyslogd reemplaza a syslogd pero aparentemente también reemplaza a klogd (más o menos: vea las notas al final).

La tercera parte es que los mensajes escritos en el búfer del anillo del núcleo desde el espacio del usuario en realidad se ven diferentes de los mensajes escritos desde el espacio del núcleo: tienen una facilidad diferente. dmesg tiene algunas opciones que interactúan con esto: -xmostrará la facilidad (y la prioridad), mientras que -uy le -kdirá a dmesg que muestre solo los mensajes de facilidad del usuario y los mensajes de facilidad del núcleo, respectivamente.

Ahora aquí está el factor decisivo: de manera predeterminada, rsyslogd ignora los mensajes con una función que no es del núcleo cuando lee mensajes del búfer de anillo del núcleo. La opción de configuración relevante es $KLogPermitNonKernelFacility, que está desactivada de manera predeterminada y debe activarse si desea que rsyslogd procese estos mensajes. Tenga en cuenta que el resto de la configuración de rsyslogd tratará todos los mensajes del búfer de anillo del núcleo como si tuvieran la kernfacilidad, independientemente de la facilidad que tenían en el búfer de anillo del núcleo.

Más información

syslog

El código puede escribir en syslog llamando a la función glibc syslog(), descrita en man 3 syslog. Aparentemente, estas funciones escriben en /dev/log. El código puede leerse desde syslog leyendo /dev/log, y esto es lo que hacen syslogdy sus reemplazos. rsyslogdlee /dev/logusando su imuxsockmódulo de entrada.

Kernel ring buffer

El espacio del kernel escribe en este búfer llamando a la función del kernel printk(), por lo que a veces se llama el búfer printk. El espacio de usuario puede escribirle escribiendo a /dev/kmsg. El espacio de usuario puede leer desde este búfer por varios métodos: puede leer /proc/kmsg(lo que hace dmesg por defecto), o puede leer /dev/kmsg, o puede llamar a la llamada al sistema syslog(), que se describe man 2 syslogy es completamente diferente de la función glibc syslog()descrita en man 3 syslog. glibc en realidad proporciona un contenedor para la llamada al sistema syslog(), llamada klogctl(), para ayudar a aliviar esta confusión.

Tradicionalmente, klogdlee desde una de estas interfaces, luego llama a la función glibc syslog()para copiarlas en el syslog. rsyslogd lee una de estas interfaces a través de su imklogmódulo de entrada, pero AFAIK no se molesta en llamar al glibc syslog(), por lo que no es exactamente como klogd; solo procesa la salida de la imklogmisma manera que procesa la salida de cualquier otro módulo de entrada. Existe la advertencia adicional de que toda la imklogsalida tiene la kernfacilidad independientemente de los mensajes de la facilidad que tenía en el búfer de anillo del núcleo.

Referencias

Vanessa Phipps
fuente
44
Gracias por la explicación detallada de por qué esto no funcionaba y cómo solucionarlo. Una de las respuestas a las preguntas vinculadas mencionadas, dmesgpero no tenía ningún sentido sin el contexto dado aquí.
Bradd Szonye
16

Encontré el mío en /var/log/upstart/

Leopd
fuente
Encontré el mío en el archivo /var/log/upstart/job.logdonde jobestá el nombre de mi trabajo.
Kenny Evitt
AFAIK es donde van los trabajos stdout / stderr de los trabajos. Esta pregunta trata sobre los mensajes de registro de Upstart, que no están asociados con ningún trabajo en particular.
Vanessa Phipps