Есть ли простой способ проверить, какая программа написана в / var / log / messages?

Есть ли простой способ проверить, какая программа написана в каком файле? Я хотел бы проверить, какая программа написала ошибку для / var / log / messages, например.

  • Автозапуск Firefox в системе CentOS 6 с помощью диспетчера отображения Gnome + Openmotif Window Manager
  • Альтернативы не работают хорошо для установки Java на Centos 6.4
  • Почему обновление пакета yum заменяет мои файлы конфигурации yum-cron?
  • Установка постоянной переменной среды в выпуске CentOS 7
  • Доля NFS на Centos 7 Не удается автоматизировать
  • Какую команду iptables нужно разрешить трафик веб-сервера?
  • От Ubuntu до Debian или CentOS
  • Почему я зарегистрирован как root, когда я использую учетные данные обычных пользователей?
  • One Solution collect form web for “Есть ли простой способ проверить, какая программа написана в / var / log / messages?”

    TL; DR

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

     Feb 18 23:07:20 greeneggs fprintd[444]: ** Message: No devices in use, exit Feb 18 23:08:53 greeneggs gnome-session[8316]: 23:08:53 | Git | personal_repo | Checking for remote changes... Feb 18 23:08:53 greeneggs gnome-session[8316]: 23:08:53 | Cmd | personal_repo | git rev-parse HEAD 

    Анализ записи

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

     $ sudo lsof -p $(pgrep syslogd) | grep '/var/log' lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. rsyslogd 733 root 5w REG 253,1 11413306 1323777 /var/log/messages rsyslogd 733 root 6w REG 253,1 61714 1318348 /var/log/cron rsyslogd 733 root 7w REG 253,1 60103 1323778 /var/log/secure rsyslogd 733 root 8w REG 253,1 49725 1323776 /var/log/maillog 

    Мы можем видеть с strace?

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

     $ sudo ps -eLf | grep rsyslogd root 733 1 733 0 4 Feb17 ? 00:00:00 /sbin/rsyslogd -n root 733 1 795 0 4 Feb17 ? 00:00:01 /sbin/rsyslogd -n root 733 1 796 0 4 Feb17 ? 00:00:00 /sbin/rsyslogd -n root 733 1 798 0 4 Feb17 ? 00:00:01 /sbin/rsyslogd -n root 27863 23659 27863 0 1 22:14 pts/2 00:00:00 grep --color=auto rsyslogd 

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

    пример

     $ sudo strace -p 795 -s 2000 -o rsyslogd.log 

    Теперь я пишу сообщение с помощью logger :

     $ logger hey 

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

     $ sudo tail -f rsyslogd.log select(4, [3], NULL, NULL, NULL) = 1 (in [3]) recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"<13>Feb 18 22:15:49 saml: hey", 8096}], msg_controllen=0, msg_flags=MSG_CTRUNC}, MSG_DONTWAIT) = 29 futex(0x7f41ba963d14, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f41ba963d10, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 futex(0x7f41ba963e70, FUTEX_WAKE_PRIVATE, 1) = 1 select(4, [3], NULL, NULL, NULL 

    Если мы strace все rsyslogd PIDs rsyslogd , rsyslogd все их выходные данные в разные файлы журналов ( me*.log где * = 1-4), а затем tail -f me*.log , теперь мы получим расширенный вид из нашей команды logger hey :

     ==> me1.log <== ) = 1 (in [3]) recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"<13>Feb 18 22:23:23 saml: hey", 8096}], msg_controllen=0, msg_flags=MSG_CTRUNC}, MSG_DONTWAIT) = 29 futex(0x7f41ba963d14, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f41ba963d10, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 ==> me3.log <== ) = 0 ==> me1.log <== select(4, [3], NULL, NULL, NULL ==> me3.log <== futex(0x7f41ba963e70, FUTEX_WAKE_PRIVATE, 1) = 0 write(5, "Feb 18 22:23:23 greeneggs saml: hey\n", 36) = 36 futex(0x7f41ba963d14, FUTEX_WAIT_PRIVATE, 67373, NULL 

    Мы можем видеть немного больше того, что происходит, но мы по-прежнему не можем точно определить, какой процесс генерировал сообщение rsyslogd .

    Как насчет использования fatrace?

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

    пример

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

     $ sudo fatrace | grep /var/log 

    Теперь, когда процессы начинают обращаться к /var/log мы получим постоянный поток процесса, который выполняет доступ.

    Вот результат, когда я запустил эту команду, sudo -i :

     systemd-journal(340): O /var/log/journal/0ee868f8b7da40f48013a281826b1b84 systemd-journal(340): C /var/log/journal/0ee868f8b7da40f48013a281826b1b84 rsyslogd(733): W /var/log/secure rsyslogd(733): W /var/log/secure auditd(546): W /var/log/audit/audit.log auditd(546): W /var/log/audit/audit.log auditd(546): W /var/log/audit/audit.log 

    Вот корень ssh , входящий в поле через localhost, ssh root@localhost :

     auditd(546): W /var/log/audit/audit.log auditd(546): W /var/log/audit/audit.log rsyslogd(733): W /var/log/messages rsyslogd(733): W /var/log/messages rsyslogd(733): W /var/log/secure sshd(23718): O /var/log/lastlog rsyslogd(733): W /var/log/secure sshd(23718): RC /var/log/lastlog sshd(23718): RCO /var/log/btmp auditd(546): W /var/log/audit/audit.log sshd(23724): RCO /var/log/lastlog sshd(23724): O /var/log/wtmp sshd(23724): W /var/log/wtmp sshd(23724): W /var/log/wtmp sshd(23724): CW /var/log/wtmp sshd(23724): CW /var/log/wtmp sshd(23724): CWO /var/log/lastlog sshd(23724): CW /var/log/lastlog 

    Таким образом, использование fatrace может помочь вам определить, какой процесс в конечном итоге приводит сообщения журнала в /var/log/messages .

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

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

     # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH SyslogFacility AUTHPRIV #LogLevel INFO 

    Таким образом, это означает, что sshd использует SyslogFacility и его только отправляющие сообщения AUTHPRIV или выше. Итак, как сообщения поступают в /var/log/messages ?

    Взгляните на конфигурационный файл rsyslogd , /etc/rsyslog.conf :

     # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages 

    ПРИМЕЧАНИЕ. Обратите внимание на authpriv на левой стороне? Это то, что «маршрутизирует» сообщения из sshd в файл, /var/log/messages .

    Рекомендации

    • Определение конкретного файла, ответственного за высокий ввод-вывод
    Linux и Unix - лучшая ОС в мире.