Seperti yang saya pahami, kernel Linux masuk ke /proc/kmsg file (kebanyakan pesan terkait perangkat keras) dan /dev/log stopkontak? Di tempat lain? Apakah aplikasi lain juga dapat mengirim pesan ke /proc/kmsg atau /dev/log ? Last but not least, apakah saya benar bahwa itu adalah daemon syslog(rsyslog , syslog-ng ) yang memeriksa pesan dari dua tempat tersebut dan kemudian mendistribusikannya ke berbagai file seperti /var/log/messages atau /var/log/kern.log atau bahkan server syslog pusat?
Jawaban yang Diterima:
Sederhananya, kurang lebih seperti ini:
Kernel mencatat pesan (menggunakan printk() function) ke buffer cincin di ruang kernel. Pesan-pesan ini tersedia untuk aplikasi ruang pengguna dalam dua cara:melalui /proc/kmsg file (asalkan /proc sudah terpasang), dan melalui sys_syslog panggilan sys.
Ada dua aplikasi utama yang membaca (dan, sampai batas tertentu, dapat mengontrol) buffer ring kernel:dmesg(1) dan klogd(8) . Yang pertama dimaksudkan untuk dijalankan sesuai permintaan pengguna, untuk mencetak konten buffer cincin. Yang terakhir adalah daemon yang membaca pesan dari /proc/kmsg (atau panggil sys_syslog , jika /proc tidak dipasang) dan mengirimkannya ke syslogd(8) , atau ke konsol. Itu mencakup sisi kernel.
Di ruang pengguna, ada syslogd(8) . Ini adalah daemon yang mendengarkan sejumlah soket domain UNIX (terutama /dev/log , tetapi yang lain juga dapat dikonfigurasi), dan secara opsional ke port UDP 514 untuk pesan. Itu juga menerima pesan dari klogd(8) (syslogd(8) tidak peduli dengan /proc/kmsg ). Ia kemudian menulis pesan-pesan ini ke beberapa file di /log , atau ke pipa bernama, atau mengirimkannya ke beberapa host jarak jauh (melalui syslog protokol, pada port UDP 514), sebagaimana dikonfigurasi dalam /etc/syslog.conf .
Aplikasi ruang pengguna biasanya menggunakan libc fungsi syslog(3) untuk mencatat pesan. libc mengirimkan pesan-pesan ini ke soket domain UNIX /dev/log (di mana mereka dibaca oleh syslogd(8) ), tetapi jika suatu aplikasi adalah chroot(2) -ed pesan mungkin akan ditulis ke soket lain, f.i. ke /var/named/dev/log . Tentu saja ini penting untuk aplikasi yang mengirimkan log ini dan syslogd(8) untuk menyetujui lokasi soket ini. Untuk alasan ini syslogd(8) dapat dikonfigurasi untuk mendengarkan soket tambahan selain dari /dev/log standar .
Terakhir, syslog protokol hanyalah protokol datagram. Tidak ada yang menghentikan aplikasi mengirim datagram syslog ke soket domain UNIX mana pun (asalkan kredensialnya mengizinkannya untuk membuka soket), melewati syslog(3) fungsi di libc sama sekali. Jika datagram diformat dengan benar syslogd(8) dapat menggunakannya seolah-olah pesan dikirim melalui syslog(3) .
Tentu saja, di atas hanya mencakup teori logging "klasik". Daemon lain (seperti rsyslog dan syslog-ng , seperti yang Anda sebutkan) dapat menggantikan syslogd(8) plain biasa , dan melakukan segala macam hal bagus, seperti mengirim pesan ke host jarak jauh melalui koneksi TCP terenkripsi, memberikan stempel waktu resolusi tinggi, dan sebagainya. Dan ada juga systemd , yang secara perlahan memfagosit bagian UNIX dari Linux. systemd memiliki mekanisme pencatatan sendiri, tetapi cerita itu harus diceritakan oleh orang lain.
Perbedaan dengan *dunia BSD:
Di *BSD tidak ada klogd(8) , dan /proc tidak ada (di OpenBSD) atau sebagian besar sudah usang (di FreeBSD dan NetBSD). syslogd(8) membaca pesan kernel dari perangkat karakter /dev/klog , dan dmesg(1) menggunakan /dev/kmem untuk memecahkan kode nama kernel. Hanya OpenBSD yang memiliki /dev/log . FreeBSD menggunakan dua soket domain UNIX /var/run/log dan var/rub/logpriv sebagai gantinya, dan NetBSD memiliki /var/run/log .