Вопросы Теги

Существует ли простой способ проверить, какая программа записала в/var/log/messages?

У меня нет диска GPT, таким образом, это - просто предположение, но это может быть то, почему fdisk имеет проблему - это не поддерживало GPT до прошлого года. Однако я замечаю, что это датировано спустя несколько месяцев после последнего стабильного util-linux (исходный пакет, который включает fdisk), 2.21, который является fdisk здесь на моей мягкой фетровой шляпе 17 систем. Можно проверить это с fdisk -v.

То сообщение, кажется, относится к версии 2.3.1, которая не доступна? Последнее ответвление по мерзавцу похоже 2.23.

Таким образом, скорее всего, Ваш fdisk не поддерживает GPT, и версия, которая делает, по-видимому, не готова для всеобщего использования. Однако gdisk, "fdisk как разделение инструмента для дисков GPT" доступен в мягкой фетровой шляпе repos (на самом деле, это уже находится в моей системе, поэтому возможно, это - часть основной установки). Если можно использовать это с живого CD, можно настроить разделы сами и сказать установщику пропускать тот шаг.

Гугля вокруг, кажется, что F19 должен поддерживать установку GPT, но у некоторых людей были проблемы...

3
19.02.2014, 06:34
1 ответ

TL;DR

Если вас интересует только определение того, какой процесс генерировал данное сообщение в

/var/log/messages, то посмотрите на первую часть каждой строки. Это покажет имя процесса вместе с PID того, кто сгенерировал данную строку. В примерах ниже, fprintd, PID 444 и gnome-session, PID 8316 сгенерировал эти строки в моём лог-файле messages.

Анализируя записи

Процессы не пишут напрямую в /var/log/messages

, а должны посылать свои сообщения в

rsyslogd

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

lsof
, чтобы посмотреть, какие файлы открываются в директории
/var/log

с помощью

rsyslogd

.

Можно ли посмотреть с помощью strace?

Таким образом, одним из подходов было бы посмотреть, какие процессы пишут в

rsyslogd
, а не в лог-файл
сообщения

напрямую. Для этого сначала нужно определить PID всех потоков

rsyslogd
.
    

  1.  С помощью PIDs в руке вы можете использовать
strace, чтобы посмотреть, как лог записывается в rsyslogd. Это немного проб и ошибок, но я смог связать этот PID и затем использовать логгер для имитации активности в моем /var/log/messages лог-файле .

  • Пример

  • Теперь я пишу сообщение, используя логгер:

  • Если мы смотрим наш лог-файл , rsyslogd. log в результате мы увидим этот тип сообщений:

    • Если мы перетащим все PID-ы rsyslogd, запишем все их выходные данные в разные лог-файлы (me*. log где * = 1-4) и затем tail -f me*.log, теперь мы получаем расширенный вид из нашей команды loger hey:Мы можем видеть немного больше о том, что происходит, но мы все еще не можем точно определить, какой процесс сгенерировал сообщение на rsyslogd. Как насчет использования fatrace?

    1. Это более новое дополнение к набору инструментов трассировки, но оно может оказаться очень полезным в таких ситуациях, как ваша. С помощью этого инструмента можно отследить всю систему доступа к файлам ввода/вывода, но мы можем сузить его область до каталога /var/log, чтобы посмотреть, не сможем ли мы узнать, какой процесс выбрасывает сообщения журнала в rsyslogd

      .

    2. Пример

    Для начала мы бы запустили эту команду, чтобы посмотреть только сообщения

    /var/log

    .

    1. Теперь, когда процессы начнут обращаться к

      /var/log

      , мы получим постоянный поток, к которому процесс обращается.

    2. Вот вывод, когда я выполнял эту команду,

      sudo -i

      :

    3. Вот root

      ssh'ing в box через localhost, ssh root@localhost

      :

    Так что использование

    fatrace

    могло бы помочь вам начать точно определять, какой процесс, в конечном счете, направляет лог-сообщения в

    /var/log/messages
    .

    Как сообщения попадают в /var/log/messages?

    Если вы берете что-то вроде SSH, то sshd, конфигурируется этим конфигурационным файлом, /etc/ssh/sshd_config. В этом файле есть эта строка, которая определяет, куда
    sshd должен посылать свои сообщения из лог-файла.

    Это значит, что sshd

    SyslogFacility, и его единственная посылающая сообщения, которая является AUTHPRIV или выше. Тогда как же сообщения попадают в /var/log/messagesrsyslogd
      ,
    /etc/rsyslog.conf:

    NOTE: Заметили authpriv

    с левой стороны? Это то, что "маршрутизирует" сообщения из

    sshd

    в файл,

    /var/log/messages

    .

    References

    Defined Specific File Responsible for High I/O

    6
    27.01.2020, 21:14

    Теги

    Похожие вопросы