En Ubuntu 12.04, puedo encontrar mensajes de registro de Upstart en /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
En Ubuntu 13.10, los mensajes no aparecen en syslog o en cualquier otro lugar bajo /var/log directorio, aunque comandos como logger hello trabajar como se esperaba. ¿Debería buscarlos en otro lugar? ¿Hay algún ajuste de configuración que deba cambiar en alguna parte?
Hay una pregunta sobre Server Fault de alguien que parece tener el mismo problema en Ubuntu 13.04, y más aquí y aquí que también pueden estar describiendo el mismo problema. Desafortunadamente, estas preguntas no ofrecen pistas para el problema.
Mejor respuesta
Editar 2016-06-02
Si está tratando de encontrar "Mensajes de registro de Upstart" en general, consulte /var/log/upstart/ . Ahí es donde Upstart guarda stdout y stderr de los servicios Upstart. Gracias a la respuesta de leopd por señalar esto.
Si está buscando mensajes de registro de Upstart, que están configurados por initctl log-priority y emitido por initctl emit , ¡sigue leyendo!
Versión corta
Las entradas de registro deberían aparecer en dmesg. A pesar de eso, no aparece por defecto en /var/log .
Si los quieres en /var/log también, agregue $KLogPermitNonKernelFacility on a la configuración de rsyslogd. Sugiero crear un archivo personalizado como /etc/rsyslog.d/60-custom.conf para evitar editar /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 la log-priority de Upstart a info más o menos.
Versión larga
Esto me tomó días para rastrear, pero aparentemente Upstart (1.5) no log a syslog, es decir, no llama a la función glibc syslog() . En su lugar, Upstart inicia sesión en el búfer de anillo del núcleo, que es lo que lee dmesg. Ahora, no pensé que fuera posible para que los procesos del espacio del usuario escriban en ese búfer, pero aparentemente pueden escribir en /dev/kmsg , y eso es exactamente lo que hace Upstart. Así que esa es la primera parte del rompecabezas.
La segunda parte es que existe la creencia generalizada de que los mensajes escritos en el búfer de anillo del kernel se copian automáticamente en syslog por el kernel (al menos eso es lo que siempre pensé). Resulta que esto en realidad lo hace un demonio de espacio 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 de anillo del kernel desde el espacio del usuario en realidad se ven diferentes de los mensajes escritos desde el espacio del kernel:tienen una función diferente. dmesg tiene algunas opciones que interactúan con esto:-x mostrará la instalación (y la prioridad), mientras que -u y -k dígale a dmesg que muestre solo los mensajes de las instalaciones del usuario y los mensajes de las instalaciones del kernel, respectivamente.
Ahora aquí está el factor decisivo:por defecto, rsyslogd ignora mensajes con una función ajena al núcleo cuando está leyendo mensajes del búfer de anillo del núcleo. La opción de configuración relevante es $KLogPermitNonKernelFacility , que está desactivado de forma 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 kernel como si tuvieran el kern instalación, independientemente de la instalación que tenían en el búfer de anillo del kernel.
Más información
registro del sistema
El código puede escribir en syslog llamando a la función glibc syslog() , descrito en man 3 syslog . Aparentemente, estas funciones escriben en /dev/log . El código se puede leer desde syslog leyendo /dev/log , y esto es lo que syslogd y sus reemplazos lo hacen. rsyslogd lee /dev/log usando su imuxsock módulo de entrada.
Búfer de anillo del núcleo
El espacio del núcleo escribe en este búfer llamando a la función del núcleo printk() , por lo que a veces se denomina búfer printk. El espacio de usuario puede escribir en él escribiendo en /dev/kmsg . El espacio de usuario puede leer desde este búfer por varios métodos:puede leer desde /proc/kmsg (lo que hace dmesg por defecto), o puede leer desde /dev/kmsg , o puede llamar a la llamada del sistema syslog() , que se describe en man 2 syslog y es completamente diferente de la función glibc syslog() descrito en man 3 syslog . glibc en realidad proporciona un contenedor para la llamada al sistema syslog() , llamado klogctl() , para ayudar a aliviar esta confusión.
Tradicionalmente, klogd lee desde una de estas interfaces, luego llama a la función glibc syslog() para copiarlos al syslog. rsyslogd lee una de estas interfaces a través de su imklog módulo de entrada pero AFAIK no se molesta en llamar a la glibc syslog() , por lo que no es exactamente como klogd; simplemente procesa la salida de imklog al igual que procesa la salida de cualquier otro módulo de entrada. Existe la advertencia adicional de que todos los imklog la salida tiene el kern instalación independientemente de los mensajes de instalación que tenían en el búfer de anillo del kernel.
Referencias
- http://upstart.ubuntu.com/cookbook/#initctl-log-priority (Indica incorrectamente que Upstart inicia sesión en 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 (Tenga en cuenta que esto es para v5, utilizado en Ubuntu 12.04. Estas opciones se consideran heredadas en versiones recientes de rsyslog)