HPUNIX Сайт о ОС и не только!

Управление бесом syslogd и журналированием в Linux

22 апреля 2009 - unix
Управление бесом syslogd и журналированием в Linux

На данный момент на речь пойдет о журналировании в Linux. Функция системного журналирования (т.н. "логи" или логирование) - это основной источник инфы о работе системы и ошибках.

Журналирование может осуществляться на локальной системе, а так же сообщения журналирования могут пересылаться на удаленную систему, не считая того, в конфигурационном файле /etc/syslog.conf (в некоторых новых дистрибутивах заменен на /etc/rsyslog.conf) возможна узенькая регулировка уровня журналирования. Журналирование осуществляется при помощи беса syslogd (rsyslogd - в некоторых новых дистрибутивах), который обычно получает входную информацию при помощи сокета /dev/log (локально) или с udp-порта 500 четырнадцать (с удаленных машин).

syslog-server:~# ls -l /dev/log srw-rw-rw- Один root root Нуль Дек Семнадцать 06:25 /dev/log

#image.jpgВ случае локального журналирования главным файлом - хранителем инфы, обычно является /var/log/messages, но в большинстве установок употребляются и многие другие файлы, которые могут быть тщательно настроены с помощью вышеуказанного конфигурационного файла. Например, может показаться необходимость выделить в отдельный лог сообщения, рождаемые бесом электронной почты.

Управление типом и подробностью журналируемой инфы

Конфигурационный файл syslog.conf

Файл syslog.conf является главным конфигурационным файлом для беса syslogd. Конфигурационный файл syslog.conf представляет собой набор правил. Каждое правило есть - строка, состоящая из селектора и деяния, разбитых пробелом или табуляцией.

Селектор представляет собой запись в виде источник.ценность. (источник временами именуют - категорией) Селектор может состоять из нескольких записей источник.ценность, разбитых символом ";" . Можно указывать несколько источников в одном селекторе (через запятую).  Поле действие - устанавливает журналируемое действие для селектора.

Получив сообщение для записи в журнал (от klogd, от локальной или удаленной программы), syslogd для каждого правила проверяет не подходит ли сообщение под шаблон, определяемый селектором. Если подходит, то делается обозначенное в правиле действие. Для 1-го сообщения м.б. выполнено случайное количество действий (т.е. обработка сообщения не прекращается при первом успехе).

Сообщения с уровнем, равным или выше обозначенного в селекторе, и источником, равным обозначенному в селекторе, считается подходящим. Звездочка перед точкой соответствует хоть какому источнику, после точки - хоть какому уровню.

Слово none после точки - никакому уровню для данного источника. Можно указывать несколько источников в одном селекторе (через запятую).

Источник (он же категория) может быть следующим:

  • 0 - kern -  Сообщения ядра
  • 1 - user -  Сообщения пользовательских программ
  • 2 - mail -  Сообщения от почтовой системы.
  • 3 - daemon - Сообщения от тех системных бесов, которые в отличие от FTP или LPR не имеют выделенных специально для их категорий.
  • 4 - auth - Все что связано с авторизацией юзеров, вроде login и su (безопасность/права доступа)
  • 5 - syslog - Система протоколирования может протоколировать сообщения от самой себя.
  • 6 - lpr - Сообщения от системы печати.
  • 7 - news - Сообщения от сервера новостей. (в настоящее время не употребляется)
  • Управление бесом syslogd и журналированием в Linux
  • 8 - uucp - Сообщения от UNIX-to-UNIX Copy Protocol. Это часть истории UNIX и вероятнее всего она для вас никогда не понадобится (хотя до сих пор определенная часть почтовых сообщений доставляется через UUCP).
  • 9 - cron - Сообщения от системного планировщика.
  • 10 - authpriv - То же самое, что и auth, но сообщения этой категории записываются в файл, который могут читать только некоторые пользователи (может быть, эта категория выделена потому, что принадлежащие ей сообщения могут содержать открытые пароли юзеров, которые не должны попадать на глаза посторонним людям, и как надо файлы протоколов должны иметь соответствующие права доступа).
  • 11 - ftp - При помощи этой категории вы сможете поменять ваш FTP сервер, что бы он записывал свои деяния.
  • 12 - NTP - сообщения сервера времени
  • 13 - log audit
  • 14 - log alert
  • 15 - clock daemon - сообщения беса времени
  • с Шестнадцать по 20 три   local0 - local7 Зарезервированные категории для использования администратором системы. Категория local7 обычно употребляется для сообщений, генерируемых на шаге загрузки системы.
  • mark (не имеющая цифрового эквивалента) - присваивается отдельным сообщениям, создаваемым самим бесом syslogd

Под ценность (степени значимости) сообщений заданы Восемь уровней значимости, которые кодируются числами от Нуль до 7:

  • 0 - emerg (старое название PANIC) - Критическая ситуация. Система неработоспособна.
  • 1 - alert - Тревога! Требуется немедленное вмешательство.
  • 2 - crit - Критическая ошибка (критическое состояние).
  • 3 - err (старое название ERROR) - Сообщение об ошибке.
  • 4 - warning (старое название WARN) - Предупреждение.
  • Управление бесом syslogd и журналированием в Linux
  • 5 - notice - Информация о каком-то обыкновенном, но принципном событии.
  • 6 - info - Информационное сообщение.
  • 7 - debug - Сообщения, создаваемые в процессе отладки.

Согласно действию, обозначенному в правиле, сообщение может быть записано в следующие назначения:

Обыденный файл

Задается полным способом, начиная со слеша (/). Поставьте перед ним дефис (-), чтобы отменить синхронизацию файла после каждой записи. Это может привести к потере инфы, но повысить производительность.

Именованные каналы

Размещение перед именем файла знака канала (|) дозволит использовать fifo (first in — first out, 1-ый пришел — 1-ый вышел) или именованный канал (named pipe) в качестве приемника для сообщений. До того как запускать (или перезапускать) syslogd, необходимо сделать fifo при помощи команды mkfifo. Временами fifo употребляются для отладки.

Терминал и консоль

Терминал, такой как /dev/console.

Удаленная машина

Чтобы сообщения пересылались на другой хост, расположите перед именованием хоста символ (@). Обратите внимание, что сообщения не пересылаются с принимающего хоста. (для работы данного назначения на клиенте и сервере в файле /etc/services должна быть прописана строчка syslog 514/udp, и открыт UTP-порт 514)

Список юзеров

Разбитый запятыми список юзеров, получающих сообщения (если пользователь зарегистрирован в системе). Сюда часто врубается пользователь root.

Управление бесом syslogd и журналированием в Linux

Все зарегистрированные пользователи

Чтобы известить всех зарегистрированных юзеров при помощи команды wall, используйте символ звездочки (*).

Управление бесом syslogd и журналированием в Linux

Пример легкого syslog.conf:

# Все сообщения ядра выдавать на консоль. #kern.*                                                 /dev/console
# Все логи уровня info или выше, не считая сообщений электронной почты, а так же # не логировать сообщения аутентификации и сообщений беса cron! *.info;mail.none;authpriv.none;cron.none                /var/log/messages
# Записывать в отдельный файл сообщения, содержащие секретную # информацию аутентификации, независимо от их уровня. authpriv.*                                              /var/log/secure
# Все сообщения почтовой системы тоже записывать в отдельный файл. mail.*                                                  -/var/log/maillog
# Логировать сообщения планировщика в файл /var/log/cron cron.*                                                  /var/log/cron
# Сообщения о чрезвычайных ситуациях должны немедленно получить # все пользователи системы *.emerg                                                 *
Управление бесом syslogd и журналированием в Linux
# Сохранять сообщения новостей уровня crit и выше в отдельный файл. uucp,news.crit                                          /var/log/spooler # Сохранять сообщения загрузки в boot.log local7.*                                                /var/log/boot.log

Как и во многих конфигурационных файлах, синтаксис следующий:

  • строки, начинающиеся с #, и пустые строки игнорируются.
  • Символ * может употребляться для указания всех категорий или всех ценностей.
  • Особенное ключевое слово none указывает, что журналирование для этой категории не должно быть выполнено для этого деяния.
  • Дефис перед именем файла (как -/var/log/maillog в этом примере) указывает, что после каждой записи журнал не должен синхронизироваться. В случае трагедии системы вы можете потерять информацию, но отключение синхронизации дозволит повысить производительность.

В синтаксисе конфигурационного файла можно поставить перед ценностью знак !, чтобы показать, что действие не должно применяться, начиная с этого уровня и выше. Похожим образом, перед ценностью можно поставить знак =, чтобы показать, что правило применяется только к этому уровню, или !=, чтобы показать, что правило применяется ко всем уровням, не считая этого. Ниже показано несколько примеров (man syslog.conf можно найти неограниченное количество других примеров):

# Посылать все сообщения ядра в /var/log/kernel. # Посылать все сообщения уровня critical и higher на удаленную машину sysloger и на консоль # Посыласть все сообщения уровня  info, notice и warning в /var/log/kernel-info # kern.*                       /var/log/kernel kern.crit                    @sysloger kern.crit                    /dev/console kern.info;kern.!err          /var/log/kernel-info
Управление бесом syslogd и журналированием в Linux
# Посылать все сообщения почтовой системы, не считая уровня info в /var/log/mail. mail.*;mail.!=info           /var/log/mail

Я постарался очень понятно работу syslogd показать на схеме:

#image.jpg

Запуск беса syslogd

Запуск беса протоколирования запускаются на шаге инициализации системы средством скрипта /etc/rc.d/init.d/syslog, но для того, чтобы задать свойства запуска, нет необходимости корректировать этот скрипт - начиная с версии 7.2, функции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian).

Вот некоторые возможные свойства запуска беса syslogd:

  • -a /folder/socket - указание дополнительного слушающего сокета (не забудьте предварительно сделать сокет)
  • -d - отладочный режим. При всем этом бес не переходит в фоновый режим и выдает все сообщения на текущий терминал;
  • -f имя-конфигурационного-файла. Задает имя альтернативного конфигурационного файла, который будет употребляться вместо данного по умолчанию /etc/syslog.conf;
  • -l список-хостов - задание списка хостов, имена которых не должны записываться с указанием полного доменного имени (FQDN - Full Qwalified Domain Name);
  • -m минут - запущенный без этой функции sysklogd через каждые 20 минут записывает в протокол сообщения категории mark (временные отметки). С помощью функции -m можно либо поменять интервал меж отметками, либо совершенно отменить выдачу таких сообщений;
  • -p socket - задание альтернативного сокета UNIX (вместо прослушиваемого по умолчанию /dev/log);
  • -r - разрешение принимать сообщения от удаленных хостов;
  • -x - запрет определения имени хоста по его адресу для предотвращения зависания при работе на одном хосте с сервером DNS.
  • -v - показать версию и окончить работу

После запуска беса syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid.

С помощью команды
kill -SIGNAL `cat /var/run/syslogd.pid`

можно выслать бесу syslogd один из следующих сигналов: SIGHUP - перезапуск беса; SIGTERM - окончание работы; SIGUSR1 - включить/выключить режим отладки.

Вообще-то в системе запускаются два беса протоколирования - syslogd и klogd. Оба беса входят в состав пакета sysklogd.

Бес klogd отвечает за журналирование событий, происходящих в ядре системы. Необходимость в отдельном демоне klogd разъясняется тем, что ядро не может использовать стандартную функцию syslog.

Дело в том, что стандартные библиотеки С (включая ту библиотеку, в какой находится функция syslog) предназначены для использования только обычными приложениями. Потому что ядро тоже нуждается в функциях журналирования, в него включены свои библиотеки, недоступные приложениям. Поэтому ядро употребляет свой собственный механизм генерации сообщений.

Бес klogd предназначен для организации обработки этих сообщений. В принципе он может создавать такую обработку полностью без помощи других и независимо от syslogd, например, записывая эти сообщения в файл, но практически всегда употребляется принятая по умолчанию настройка klogd, при которой все сообщения от ядра пересылаются тому же бесу syslogd.

Автоматическая ротация (обновление заполненных файлов) и архивирование журналов

Со временем, файл журнала имеет свойство возрастать, в особенности при насыщенной работе какого-либо сервиса. Соответственно, необходимо иметь возможность контролировать размер журналов.

Это делается при помощи команды logrotate, которая обычно делается бесом cron. О работе cron я расскажу в следующих статьях.

Основная цель команды logrotate состоит в том, чтобы периодически создавать запасные копии журналов и создавать новые незапятнанные журнальчики. Сохраняется несколько поколений журналов и, когда завершается срок жизни журнала последнего поколения, он может быть заархивирован (сжат). Результат может быть отправлен по почте, например, ответственному за ведение архивов.

Для определения порядка ротации и архивирования журналов употребляется конфигурационный файл /etc/logrotate.conf. Для разных журналов можно задать разную периодичность, например, раз в денек, раз в неделю или каждый месяц, не считая того, можно регулировать количество накапливаемых поколений, также указать, будут ли копии архивов отправляться ответственному за ведение архивов и, если будут, когда. Ниже показан пример файла /etc/logrotate.conf:

# сначала заданы свойства "по-умолчанию" (глобальные функции) # обновлять файлы журнала раз в неделю weekly
# хранить архив логов за Четыре последние недели rotate Четыре # создавать новый (пустой) файл после ротации (обновления) create
# раскомментируйте, если желаете, чтобы сохраненные файлы сжимались #compress
# включить функции ротации из обозначенного каталога include /etc/logrotate.d
# не хранить wtmp, или btmp -- функции ротации данных журналов следующие: /var/log/wtmp { missingok monthly create 600 шестьдесят четыре root utmp rotate Один }
/var/log/btmp { missingok monthly create 600 шестьдесят четыре root utmp rotate Один }
# специфичные системные журнальчики могут быть настроены ниже

Глобальные функции размещаются поначалу файла logrotate.conf.

Они употребляются по умолчанию, если где-то в другом месте не задано ничего более определенного. В примере ротация журналов происходит раз в неделю и запасные копии сохраняются в течение 4 недель.

Как делается ротация журнала, на месте старого журнала автоматом создается новый. Файл logrotate.conf может содержать спецификации из других файлов. Так, в него врубаются все файлы из каталога /etc/logrotate.d.

В этом примере также содержатся особенные правила для /var/log/wtmp и /var/log/btmp (хранящие информацию о удачных и неудачных попытках входя в систему), ротация которых происходит каждый месяц. Если файлы отсутствуют, сообщение об ошибке не выдается. Создается новый файл и сохраняется только одна запасная копия.

В этом примере по достижении запасной копией последнего поколения она удаляется, потому что не определено, что следует с ней делать.

Запасные копии журналов могут также создаваться, когда журнальчики достигают определенного размера, и могут быть изготовлены скрипты из наборов команд для выполнения до или после операции запасного копирования. Пример:

/var/log/messages { rotate 5 mail logadmin@sysloger size 100k postrotate /usr/bin/killall -HUP syslogd endscript }

В этом примере ротация /var/log/messages делается по достижении им размера 100 КБ. Накапливается 5 запасных копий, и когда исходит срок жизни самой старой запасной копии, она отсылается по почте на адрес logadmin@sysloger.

Командное слово postrotate включает скрипт, перезапускающий бес syslogd после окончания ротации способом отправки сигнала HUP. Командное слово endscript необходимо для окончания скрипта, также в случае, если имеется скрипт prerotate. Более полную информацию см. в страницах управления man для logrotate.

Свойства, задаваемые в конфигурационном файле logrotate.conf:

  • compress | nocompress (старые версии сжимаются или не сжимаются с помощью gzip)
  • compresscmd (задает программу сжатия, по умолчанию - gzip)
  • uncompresscmd (задает программу разжатия, по умолчанию - ungzip)
  • compressext (задает суффикс для сжатых файлов)
  • compressoptions (задает свойства программы сжатия; по умолчанию - "-9", т.е. наибольшее сжатие для gzip)
  • copytruncate | nocopytruncate (обычно старая версия переименовывается и создается новая версия журнала; при задании этого параметра logrotate копирует журнал в новый файл, а позже обрезает старый; употребляется, если программа, создающая журнал, не умеет его закрывать; теряются записи, сделанные в промежутке меж копированием и обрезанием; а поможет ли, если создающая журнал программа вместо режима append просто пишет в файл, используя внутренний указатель?)
  • create [права-доступа владелец группа] | nocreate (слету после переименования старой версии журнала и до вызова postrotate создается новый журнал с обозначенными атрибутами - права доступа задаются в восьмеричном виде, как в chmod.2; если атрибуты не указаны, то берутся от старого журнала)
  • daily (смена версий в серии происходит раз в денек)
  • delaycompress | nodelaycompress (некоторые программы не слету закрывают журнал, в этом случае сжатие необходимо отложить до следующего цикла)
  • errors email (кому направлять сообщения об ошибках)
  • extension суффикс (задается суффикс, добавляемый к именам файлов при ротации перед суффиксом сжатия)
  • ifempty | notifempty (смена версий даже если файл пуст; действует по умолчанию)
  • include имя-файла | имя-директории (текстуально подставить файл или все файлы из обозначенной директории; не врубаются поддиректории, особенные файлы и файлы с суффиксами из списка исключений; нельзя использовать внутри секции)
  • mail адрес | nomail (когда смена версий приводит к необходимости удалить старый журнал, то выслать его по обозначенному адресу)
  • mailfirst (посылать не удаляемую версию журнала, а первую)
  • maillast (посылать удаляемую версию журнала; действует по умолчанию)
  • missingok | nomissingok (не посылать сообщения об ошибке, если журнал отсутствует)
  • monthly (смена версий происходит каждый месяц)
  • olddir директория | noolddir (во время смены версий журнал перемещается в обозначенную директорию; д.б. на том же физическом устройстве)
  • postrotate (все следующие строчки до строки endscript исполняются как команды shell после процесса смены версии)
  • prerotate (все следующие строчки до строки endscript исполняются перед процессом смены версии)
  • rotate число (сколько старых версий хранить; если 0, то ни одной)
  • size б (смена версии происходит, если размер журнала превысил обозначенное число; можно использовать суффиксы "k" - кб - и "M" - мб)
  • sharedscripts | nosharedscripts (делать команды prerotate и postrotate только один раз для всех файлов, обрисованных в секции)
  • tabooext [+] список-суффиксов (задание списка суффиксов-исключений для include; если указан знак "плюс", то дополнение, по другому замена; по умолчанию: .rpmorig, .rpmsave, .rpmnew, ",v", .swp и "~")
  • weekly (смена версий происходит раз в неделю)

Исследование и мониторинг журналов

Записи в журналах обычно содержат метку времени, имя хоста, на котором делается описываемый процесс, и имя процесса. Просматривать журнальчики можно при помощи программы постраничного вывода, например, less, отыскивать определенные записи (например, сообщения ядра от определенного беса) можно при помощи команды grep:

[root@syslog-server ~]# less /var/log/messages [root@syslog-server ~]# grep "ppp" /var/log/messages | tail Dec Семнадцать 16:34:25 proxy pppd[7843]: Connection terminated. Dec Семнадцать 16:34:25 proxy pppd[7843]: Exit.

Dec Семнадцать 16:35:57 proxy pppd[11345]: LCP terminated by peer (^P]kV^@<M-Mt^@^@^@^@) Dec Семнадцать 16:35:57 proxy pppd[11345]: pptpd-logwtmp.so ip-down ppp2 Dec Семнадцать 16:35:57 proxy pppd[11345]: Connect time 14.8 minutes. Dec Семнадцать 16:35:57 proxy pppd[11345]: Sent 100 30 тыщ 100 девяносто два bytes, received 50 три тыщи девятьсот 40 6 bytes.

Dec Семнадцать 16:35:57 proxy pppd[11345]: Modem hangup Dec Семнадцать 16:35:57 proxy pppd[11345]: Connection terminated. Dec Семнадцать 16:35:57 proxy pppd[11345]: Script /etc/ppp/ip-down finished (pid 12084), status = 0x1 Dec Семнадцать 16:35:57 proxy pppd[11345]: Exit.

Компьютер может работать не постоянно и выключаться, допустим на ночь. Поэтому в /var/log/messages записи хранятся циклически от запуска компьютера к выключению, это можно узреть по сообщениям:

Дек Семнадцать 08:32:56 syslog-server syslogd 1.4-0: restart. Дек Семнадцать 08:32:56 syslog-server syslog: запуск syslogd succeeded Дек Семнадцать 08:32:56 syslog-server kernel: klogd 1.4-0, log source = /proc/kmsg started. Дек Семнадцать 08:32:56 syslog-server syslog: запуск klogd succeeded

Далее в файле протокола можно отыскать версию ядра, свойства его запуска, информацию о типе процессора и объеме ОЗУ:

Dec Семнадцать 08:32:56 syslog-server kernel: Kernel command line: auto BOOT_IMAGE=linux ro root=303 BOOT_FILE=/boot/vmlinuz-2.4.2-2 Dec Семнадцать 08:32:56 syslog-server kernel: Memory: 125652k/130560k available (1365k kernel code, 4200k reserved, 92k data, 236k init, 0k highmem) Dec Семнадцать 08:32:56 syslog-server kernel: CPU: Intel(R) Pentium(R) Четыре CPU 1.60GHz stepping 02

Так же, в этом файле можно найти информацию о дисковой памяти (включая информацию о геометрии диска, структуре разделов и используемых прерываниях), информацию о периферийных устройствах, о запуске отдельных служб и сервисов, информацию о подключении файловых систем и сообщения о входе юзеров в систему, также сообщения об ошибках.

Временами может появляться необходимость мониторинга системных журналов с целью поиска текущих событий. Например, можно испытать поймать время от времени случающееся событие тогда, когда оно вышло. В таком случае можно использовать команду tail с опцией -f для отслеживания содержимого системного журнала. Пример:

[root@syslog-server~]# tail -f /var/log/messages | grep syslog-server Dec Семнадцать 16:46:09 syslog-server pppd[12548]: pptpd-logwtmp.so ip-up ppp0 maikop 94.77.0.150 Dec Семнадцать 16:46:09 syslog-server pppd[12548]: Script /etc/ppp/ip-up finished (pid 12552), status = 0x0 Dec Семнадцать 16:46:49 syslog-server pptpd[12581]: CTRL: Client 85.175.197.65 control connection started Dec Семнадцать 16:46:49 syslog-server pptpd[12581]: CTRL: Starting call (launching pppd, opening GRE) Dec Семнадцать 16:46:49 syslog-server pppd[12582]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.

Не считая файлов-журналов, обозначенных в /etc/syslog.conf, есть так же и другие файлы, например файл /var/log/dmesg,  который хранит информацию о процессе загрузки системы до запуска syslogd, а так же файлы /var/log/lastlog, /var/log/wtmp, /var/log/btmp, имеющие двоичный формат и и хранящие информацию о последнем входе пользователя в систему, о всех удачных входах юзеров в систему и о всех неудачных входах юзеров в систему соответственно.

Так же в каталоге /var/log/ могут находится лог-файлы таких бесов как веб-сервер или прокси-сервер. Формат данных файлов аналогичен журнальчикам syslogd.

На последок, хотелось бы сделать акцент на том, что данный протокол очень не защищен, т.к. syslog не содержит никаких средств защиты от подделок сообщений. Ужаснее того, внедрение протокола UDP позволяет злодеям посылать сообщения от имени хоть какого хоста.

Ваша локальная сеть должна быть защищена экраном от приема пакетов с поддельными локальными адресами (хотя это не помешает посылать поддельные сообщения изнутри локальной сети) и от приема пакетов снаружи на порт 514/udp. Известны случаи переполнения диска неправильными сообщениями.

Протокол syslog и UDP не обеспечивают гарантированной доставки (сообщения могут быть потеряны при перегрузке сети или перехвачены, поврежденные сообщения удаляются без предупреждения), правильной последовательности доставки (сообщение о окончании процесса может придти ранее сообщения о его запуске), приоритетной доставки.

Конфиденциальность сообщений не обеспечивается, так как они передаются открытым текстом.

Если при настройке генератора сообщений указать неправильный адрес коллектора или релея, то никаких сообщений об ошибке не будет - сообщения будут удаляться (или записываться в чужой журнал).

Были предложены несколько проектов улучшения протокола syslog. Например, документ RFC Три тыщи 100 девяносто 5 предлагает систему протоколирования (syslog-conn), основанную на TCP, обеспечивающую гарантированную доставку сообщений в правильной последовательности. Проект syslog-sign предлагает обеспечить аутентификацию, упорядоченность, целостность сообщений и обнаружение пропавших сообщений за счет генерации особенных сообщений, содержащих цифровую подпись (signature) блока прошедших сообщений с сохранением стандартного протокола и формата syslog и внедрением UDP.

Подведем небольшой итог:

В линукс есть единый бес, отвечающий за журналирование событий локальной системы и удаленных систем. Все деяния собираются из сокета /dev/log, порта UDP - 514, а так же от "помощника" - беса klogd, который присылает сообщения от ядра.

Все собранные сообщения фильтруются бесом syslogd через правила в файле /etc/syslog.conf и в согласовании с правилами распределяются по подходящим местам назначения. Файлы логов периодически "обрезаются". Периодичность определяет файл logrotate.conf и команда logrotate, которая запускается системным планировщиком - cron.

На сегодня это все. Надеюсь описал все очень понятно. Со временем буду дополнять статью!

Похожие статьи

Теги: ос linux, ос
Рейтинг: +2 Голосов: 70 1912 просмотров
Комментарии (0)

Нет комментариев. Ваш будет первым!

Найти на сайте: параметры поиска

Windows 7

Среда Windows 7 на первых порах кажется весьма непривычной для многих.

Windows 8

Если резюмировать все выступления Microsoft на конференции Build 2013.

Windows XP

Если Windows не может корректно завершить работу, в большинстве случаев это

Windows Vista

Если к вашему компьютеру подключено сразу несколько мониторов, и вы регулярно...