Розуміння входу в Linux

Як я розумію, ядро ​​Linux записує /proc/kmsgфайли (переважно повідомлення, пов'язані з обладнанням) і /dev/logсокет? Ніде? Чи інші програми також можуть надсилати повідомлення на /proc/kmsgабо /dev/log? І останнє , але не в останню чергу, я правильно , що це системний журнал демон ( Rsyslog , Syslog-нг ) , який перевіряє повідомлення з цих двох місць , а потім розподіляє їх в різні файли , таких як /var/log/messagesчи /var/log/kern.logабо навіть центральний сервер системного журналу?

Спрощено, це виглядає більш-менш так:

Ядро записує повідомлення (використовуючи printk()функцію) в буфер кільця в просторі ядра. Ці повідомлення стають доступними для додатків у просторі користувачів двома способами: через /proc/kmsgфайл (за умови, що /procвстановлено) та через sys_syslogсистемний виклик.

Є два основні програми, які читають (і певною мірою можуть контролювати) кільцевий буфер ядра: dmesg(1)і klogd(8). Перший призначений для запуску на вимогу користувачів, для друку вмісту буфера дзвінка. Останній - демон, який читає повідомлення з /proc/kmsg(або дзвінків sys_syslog, якщо /procвони не встановлені) та надсилає їх до syslogd(8)консолі. Це покриває сторону ядра.

У користувальницькому просторі є syslogd(8). Це демон, який прослуховує декілька розеток домену UNIX (головним чином /dev/log, але інші також можуть бути налаштовані), і необов'язково на порт 514 UDP для повідомлень. Він також отримує повідомлення від klogd(8)( syslogd(8)це не хвилює /proc/kmsg). Потім він записує ці повідомлення в деякі файли в /logабо в іменовані труби, або надсилає їх деяким віддаленим хостам (через syslogпротокол, на порту 514 UDP), як налаштовано в /etc/syslog.conf.

Програми для користувальницького простору зазвичай використовують цю libcфункцію syslog(3)для реєстрації повідомлень. libcнадсилає ці повідомлення в сокет домену UNIX /dev/log(там, де їх читає syslogd(8)), але якщо програма є chroot(2)-ed, повідомлення можуть закінчитися записом в інші сокети, to до /var/named/dev/log. Звичайно, важливо для програм, що надсилають ці журнали, і syslogd(8)домовитись про розташування цих розеток. З цієї причини syslogd(8)можна налаштувати прослуховування додаткових розеток на відміну від стандартних /dev/log.

Нарешті, syslogпротокол - це просто протокол дейтаграми. Ніщо не зупиняє програму надсилати дейтаграми syslog до будь-якого сокета домену UNIX (за умови, що його облікові дані дозволяють йому відкривати сокет), повністю обходячи syslog(3)функцію libc. Якщо дейтаграми правильно відформатовані, syslogd(8)можна використовувати їх так, як якщо б повідомлення були надіслані syslog(3).

Звичайно, вищесказане охоплює лише "класичну" теорію лісозаготівлі. Інші демони (наприклад, rsyslogі syslog-ng, як ви згадуєте) можуть замінити звичайну syslogd(8)і робити всілякі витончені речі, як-от відправлення повідомлень віддаленим хостам через зашифровані TCP-з'єднання, надання часових позначок високої роздільної здатності тощо. І є також те systemd, що повільно фагоцитується частина UNIX Linux. systemdмає свої механізми лісозаготівлі, але цю історію повинен був розповісти хтось інший. :)

Відмінності зі світом * BSD:

У * BSD немає klogd(8), /procабо або не існує (на OpenBSD), або є в основному застарілим (на FreeBSD та NetBSD). syslogd(8)читає повідомлення ядра з символьного пристрою /dev/klogта dmesg(1)використовує /dev/kmemдля декодування імен ядра. Тільки OpenBSD має a /dev/log. FreeBSD використовує два сокети UNIX /var/run/logі var/rub/logprivзамість цього, і NetBSD має /var/run/log.

Інша відповідь пояснює, як каже її автор, "класичний журнал" в Linux. Це не так, як зараз працюють у багатьох системах.

Ядро

Механізми ядра змінилися.

Ядро генерує вихід в буфер пам'яті. Програмне забезпечення додатків може отримати доступ до цього двома способами. Підсистема ведення журналу зазвичай отримує доступ до неї як псевдо-FIFO з назвою /proc/kmsg. Це джерело інформації журналу не може бути корисним для спільного використання серед читачів журналів, оскільки воно читається один раз. Якщо декілька процесів поділяють його, кожен отримує лише частину потоку даних журналу ядра. Це також лише для читання.

Інший спосіб отримати доступ до нього - це новий /dev/kmsgпристрій символів. Це інтерфейс читання-запису, який можна поділити серед декількох клієнтських процесів. Якщо багато процесів поділяють його, усі вони зчитують один і той же повний потік даних, не впливаючи один на одного. Якщо вони відкриють його для доступу до запису, вони також можуть вводити повідомлення в потік журналу ядра, як якщо б вони були створені ядром.

/proc/kmsgі /dev/kmsgнадати дані журналу у формі, яка не є RFC-5424.

Програми

Заявки змінилися.

Функція бібліотеки GNU C syslog()в головних спробах підключитися до AF_LOCALсокета дейтаграми з ім'ям /dev/logі записати в нього записи журналу. (Сьогодні syslog()функція бібліотеки BSD C використовується /var/run/logяк ім'я сокета і намагається /var/run/logprivспочатку.) Програми, звичайно, можуть мати власний код, щоб це зробити безпосередньо. Функція бібліотеки - це просто код (для відкриття, підключення, запису та закриття сокета), що виконується в контексті власного процесу програми.

Програми також можуть надсилати повідомлення RFC 5424 через UDP на локальний сервер RFC 5426, якщо хтось слухає в гнізді AF_INET/ AF_INET6дейтаграмі на пристрої.

Завдяки тиску з боку daemontools протягом останніх двох десятиліть, багато dæmons підтримують роботу в режимі, коли вони не використовують syslog()функцію бібліотеки GNU C або UDP-сокети, а просто випльовують свої дані журналу до стандартної помилки в звичайна мода Unix.

управління журналом з noh та сімейством daemontools взагалі

З набором інструментів daemontools існує велика гнучкість в журналі. Але в цілому по всій родині ідея полягає в тому, що кожен "головний" dæmon має пов'язаний dæmon "реєстрації". "main" dæmons працює так само, як і не-dæmon-процеси, і записує свої журнальні повідомлення на стандартну помилку (або стандартний вихід), яку підсистема управління послугами вважає підключеною через трубу (яку він тримає відкритою, щоб дані журналу не втрачалися за перезапуск служби) до стандартного вводу dæmon "ведення журналу".

Усі dæmons "ведення журналів" запускають програму, яка десь реєструється . Зазвичай ця програма є чимось подібним multilogабо тим, cyclogщо читається зі свого стандартного вводу та записує (наносекундне часове позначення) файли журналів у суворо обмежений розмір, автоматично обертається, ексклюзивно записується, в каталог. Взагалі, ці dæmons також працюють під егідами окремих спеціалізованих непривілейованих облікових записів користувачів.

Таким чином, в кінцевому підсумку складається система, що має велику кількість розподілених журналів, і дані журналу кожної служби обробляються окремо.

Один може запустити що - щось подібне klogdабо syslogdабо rsyslogdпід керівництвом служби Daemontools сім'ї. Але світ daemontools зрозумів багато років тому, що структура управління сервісом з "реєстрацією" dæmons піддається досить акуратно робити справи простішим способом. Немає необхідності розміщувати всі потоки журналів в одному гігантському міш-месі, розбирати дані журналу, а потім вентилювати потоки назад, щоб розділити файли журналів; а потім (у деяких випадках) закрутити ненадійний механізм повороту зовнішньої колоди збоку. Структура сім'ї daemontools як частина його стандартного управління журналом вже виконує обертання журналу, запис журналу та розділення потоку.

Крім того: модель завантаження ланцюга скасування привілеїв із інструментами, що є загальними для всіх служб, означає, що в програмах реєстрації даних немає необхідності в привілеях суперпользователя; а модель UCSPI означає, що їм потрібно дбати лише про відмінності, такі як транспортування потоку проти дейтаграми.

Набір інструментів "ніш" - це приклад. Хоча ви можете запускатись rsyslogdпід ним, поза коробкою та просто керувати /run/logвведенням ядра , та журналу UDP по-старому; він також пропонує більше "рідних демонів" способів реєстрації цих речей:

• klogdслужба , яка читає /proc/kmsgі пише просто , що потік журналу в стандартній помилки. Це робиться за допомогою простої програми з назвою klog-read. Асоційований dæmon журналу подає потік журналу на його стандартному вході в /var/log/sv/klogdкаталог журналів.
• local-syslog-readслужба , яка читає датаграми /dev/log( /run/logна BSDs) і просто пише , що потік журналу в стандартній помилки. Це робиться програмою з назвою syslog-read. Асоційований dæmon журналу подає потік журналу на його стандартному вході в /var/log/sv/local-syslog-readкаталог журналів.
• udp-syslog-readсервіс , який прослуховує порт UDP системного журналу, читає те , що він відправляється до нього і просто записує потік , що лог його стандартної помилки. Знову ж таки програма syslog-read. Асоційований dæmon журналу подає потік журналу на його стандартному вході в /var/log/sv/udp-syslog-readкаталог журналів.
• (на BSD) local-priv-syslog-readсервіс, який читає дейтаграми з /run/logprivта просто записує цей потік журналу до його стандартної помилки. Знову ж таки програма syslog-read. Асоційований dæmon журналу подає потік журналу на його стандартному вході в /var/log/sv/local-priv-syslog-readкаталог журналів.

Набір інструментів також постачається з export-to-rsyslogінструментом, який може контролювати один або декілька каталогів журналу (використовуючи систему не нав'язливих курсорів журналів ) та надсилати нові записи у формі RFC 5424 по мережі на призначений сервер RFC 5426.

управління журналом з systemd

Systemd має єдину монолітну програму управління журналом, systemd-journald. Це працює як служба, якою керує systemd.

• Він читає /dev/kmsgдані журналу ядра.
• Він читає /dev/log(символічне посилання /run/systemd/journal/dev-log) для каротажних даних програми з бібліотеки GNU C в syslog()функції.
• Він слухає в AF_LOCALsocket потоку at /run/systemd/journal/stdoutдля даних журналу, що надходять із систем, керованих системою.
• Він прослуховує AF_LOCALсокет дейтаграми at /run/systemd/journal/socketдля даних журналу, що надходять від програм, які говорять про специфічний для системи протокол журналу (наприклад, sd_journal_sendv()та ін.).
• Це змішує все це разом.
• Він записує до набору файлів журналу на загальносистемному рівні та для кожного користувача, у /run/log/journal/або /var/log/journal/.
• Якщо він може підключитися (як клієнт) до AF_LOCALсокета дейтаграми, /run/systemd/journal/syslogвін записує туди дані журналу, якщо налаштовано пересилання в syslog.
• Якщо налаштовано, він записує дані журналу в буфер ядра за допомогою /dev/kmsgмеханізму, що записується .
• Якщо налаштовано, він записує дані журналу в термінали та на консольний пристрій.

Погані речі трапляються в усьому світі, якщо ця програма виходить з ладу або служба припиняється.

systemd сам організовує приєднання до /run/systemd/journal/stdoutсокета стандартних виходів та помилок (деяких) служб . Таким чином, dæmons, які входять до стандартної помилки у звичайному вигляді, надсилають їх до журналу.

Це повністю витісняє klogd, syslogd, syslog-ng та rsyslogd.

Тепер вони повинні бути специфічними для системи. У системній системі вони не можуть бути сервером /dev/log. Натомість вони використовують один із двох підходів:

• Вони стають серверним кінцем /run/systemd/journal/syslog, до якого (якщо ви пам’ятаєте) systemd-journaldнамагаються підключити та записати дані журналу. Пару років тому, хтось налаштував би imuxsockметод введення rsyslogd для цього.
• Вони читають безпосередньо з системного журналу, використовуючи специфічну для системи бібліотеку, яка розуміє формат бінарних журналів і може контролювати файли журналу та каталог для додавання нових записів. Сьогодні для цього можна налаштувати метод imjournalвведення rsyslogd .