Según tengo entendido, el kernel de Linux inicia sesión en /proc/kmsg archivo (principalmente mensajes relacionados con el hardware) y /dev/log ¿enchufe? ¿En cualquier otro lugar? ¿Hay otras aplicaciones que también pueden enviar mensajes a /proc/kmsg? o /dev/log ? Por último, pero no menos importante, tengo razón en que es el demonio syslog (rsyslog , syslog-ng ) que verifica los mensajes de esos dos lugares y luego los distribuye a varios archivos como /var/log/messages o /var/log/kern.log o incluso servidor syslog central?
Respuesta aceptada:
Simplificado, es más o menos así:
El kernel registra los mensajes (utilizando printk() función) a un búfer de anillo en el espacio del kernel. Estos mensajes están disponibles para las aplicaciones de espacio de usuario de dos maneras:a través de /proc/kmsg archivo (siempre que /proc está montado) y a través de sys_syslog llamada al sistema.
Hay dos aplicaciones principales que leen (y, hasta cierto punto, pueden controlar) el búfer circular del kernel:dmesg(1) y klogd(8) . El primero está diseñado para que los usuarios lo ejecuten a pedido, para imprimir el contenido del búfer circular. Este último es un demonio que lee los mensajes de /proc/kmsg (o llama a sys_syslog , si /proc no está montado) y los envía a syslogd(8) , o a la consola. Eso cubre el lado del kernel.
En el espacio de usuario, hay syslogd(8) . Este es un demonio que escucha en varios sockets de dominio UNIX (principalmente /dev/log , pero también se pueden configurar otros), y opcionalmente al puerto UDP 514 para mensajes. También recibe mensajes de klogd(8) (syslogd(8) no le importa /proc/kmsg ). Luego escribe estos mensajes en algunos archivos en /log , o a conductos con nombre, o los envía a algunos hosts remotos (a través de syslog protocolo, en el puerto UDP 514), según lo configurado en /etc/syslog.conf .
Las aplicaciones de espacio de usuario normalmente usan libc función syslog(3) para registrar mensajes. libc envía estos mensajes al socket de dominio UNIX /dev/log (donde son leídos por syslogd(8) ), pero si una aplicación es chroot(2) -ed los mensajes podrían terminar siendo escritos en otros sockets, p.i. a /var/named/dev/log . Por supuesto, es esencial para las aplicaciones que envían estos registros y syslogd(8) acordar la ubicación de estas tomas. Por esta razón syslogd(8) se puede configurar para escuchar sockets adicionales además del estándar /dev/log .
Finalmente, el syslog El protocolo es solo un protocolo de datagrama. Nada impide que una aplicación envíe datagramas syslog a cualquier socket de dominio UNIX (siempre que sus credenciales le permitan abrir el socket), sin pasar por syslog(3) función en libc completamente. Si los datagramas tienen el formato correcto syslogd(8) puede usarlos como si los mensajes fueran enviados a través de syslog(3) .
Por supuesto, lo anterior cubre solo la teoría de registro "clásica". Otros demonios (como rsyslog y syslog-ng , como mencionas) puede reemplazar el simple syslogd(8) y hacer todo tipo de cosas ingeniosas, como enviar mensajes a hosts remotos a través de conexiones TCP encriptadas, proporcionar marcas de tiempo de alta resolución, etc. Y también está systemd , que está fagocitando lentamente la parte UNIX de Linux. systemd tiene sus propios mecanismos de registro, pero esa historia tendría que ser contada por alguien más. 🙂
Diferencias con el mundo *BSD:
En *BSD no hay klogd(8) y /proc no existe (en OpenBSD) o está casi obsoleto (en FreeBSD y NetBSD). syslogd(8) lee los mensajes del kernel desde el dispositivo de caracteres /dev/klog y dmesg(1) usa /dev/kmem para decodificar los nombres del kernel. Solo OpenBSD tiene un /dev/log . FreeBSD utiliza dos sockets de dominio UNIX /var/run/log y var/rub/logpriv en su lugar, y NetBSD tiene un /var/run/log .