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

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

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 .

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

  • Определение конкретного файла, ответственного за высокий ввод-вывод
  • Как скопировать zip-файл из Windows в CentOS
  • Надежная и постоянная установка драйвера Nvidia на Centos 5
  • Как проверить правильную настройку пароля без пароля от userA к userB, из сеанса userB
  • Команда lsof слишком длинна для определенного идентификатора процесса
  • Нет интернет даже с iptables ПРИНИМАЕТ все
  • Служба mariadb не запускается после загрузки, CentOS 7
  • Установите графический интерфейс (KDE) на centos 5.3
  • Удаление noexec из папки Home
  • Как настроить группу (gid) процесса, который я собираюсь запустить?
  • Как безопасно удалить Exim4 на CentOS?
  • сборка массива mdadm вызывает зависание ядра
  • Linux и Unix - лучшая ОС в мире.