Гораздо более многословный /var/log/*

Я помню времена, когда, вероятно, буквально каждое лог-сообщение помещалось в /var/log/messages а также /var/log/syslog, Это был год 2000, если кому-то любопытно. Теперь все по-другому. Лог-файлы должны быть в порядке, но вместо них в IMO просто отсутствуют записи. В моем восприятии 90% проблемных ситуаций просто молчат, нет способа найти что-либо в /var/log файлы.

Как иметь /var/log/messages назад и действительно ли это многословно?

PS. В качестве примера. Когда я устанавливаю vsftpd и делаю:

sudo restart vsftpd

то, что входит в системный журнал, это следующая строка:

kernel: [ 7167.143648] init: vsftpd main process (5823) killed by TERM signal

Это единственный эффект перезапуска FTP-сервера. Подумайте об этом - возможно ли, что vsftpd не выводит баннер при запуске? Мне трудно верить.

Кроме того, журнал исходит от ядра, это ловит dmesg. Это нелепо. Если ядро ​​не перехватит сигнал TERM, в журналах не будет трассировки о перезапуске демона FTP. Это тот случай, когда proftpd перезапускается через /etc/init.d/proftpd, Никаких следов в журналах, кроме /var/log/proftpd/proftpd.log который proftpdсобственный файл журнала, настроенный SystemLog вариант.

PS2: я прилагаю результаты из Virtual Linux, вероятно, первого живого CD, созданного на основе Mandrake, начиная с 2001 года (ядро 2.4.3-20mdk). Перезапуск proftpd дает там (в /var/log/messages):

proftpd[2699]: ProFTPD killed (signal 15)
proftpd[2699]: ProFTPD 1.2.2rc1 standalone mode SHUTDOWN
proftpd: proftpd shutdown succeeded
proftpd[2730]: ProFTPD 1.2.2rc1 (release) (built Sun Apr 8 09:53:35 CEST 2001) standalone mode STARTUP
proftpd: proftpd startup succeeded

14.04 syslog пусто, а следующий зарегистрирован в proftpd.log,

proftpd[1326] asus-1201N: ProFTPD killed (signal 15)
proftpd[1326] asus-1201N: ProFTPD 1.3.5rc3 standalone mode SHUTDOWN
proftpd[2620] asus-1201N: ProFTPD 1.3.5rc3 (devel) (built Fri Dec 20 2013 18:04:47 UTC) standalone mode STARTUP

На VLinux авторизовано следующее messages когда sshd перезапущен:

sshd[2821]: Received signal 15; terminating
sshd: sshd shutdown succeeded
sshd[2924]: Server listening on 0.0.0.0 port 22.
sshd[2924]: Generating 768 bit RSA key.
sshd: sshd startup succeeded
sshd[2924]: RSA key generation complete

14.04 syslog пусто, а следующий зарегистрирован в auth.log (почему там?):

Nov 28 09:11:22 asus-1201N sshd[2500]: Received signal 15; terminating.
Nov 28 09:11:22 asus-1201N sshd[2634]: Server listening on 0.0.0.0 port 22.
Nov 28 09:11:22 asus-1201N sshd[2634]: Server listening on :: port 22.

Таким образом, в основном две строки, если не считать третью строку IPv6. Затем я ввел ошибку в sshd_config и повторил перезагрузки. VLinux / messages:

sshd[2924]: Received signal 15; terminating.
sshd: sshd shutdown succeeded
sshd: sshd startup failed

На этот раз 14.04 auth.log пусто и syslog не является:

kernel: [ 2905.854777] init: ssh main process (2718) terminated with status 255
kernel: [ 2905.854836] init: ssh main process ended, respawning

На VLinux есть подробное сообщение об ошибке в файле конфигурации, напечатанном в консоли, на которой я выпускаю /etc/init.d/sshd restart ("Неверная опция конфигурации: ..."). Интересно, когда sshd будет запущен системой, то сообщение будет зарегистрировано в messages, Я думаю, да, но я не могу проверить это с живым CD.

При перезапуске proftpd с ошибкой в ​​конфигурационных журналах полная информация о VLinux и 14.04 выводится сообщение об ошибке в терминал при повторном выполнении, и ничего, кроме "SHUTDOWN", не регистрируется в proftpd.log (syslog пустой).

Резюме:

• Я не мог доказать, что messages было больше информации, однако можно увидеть, что сейчас преобладает экономия дискового пространства (?), а не журналирование слишком много
• нужно прыгать между auth.log, syslog и выделенные журналы, чтобы найти некоторую информацию, и это в основном бессмысленный контент, так как очевидно, что никакой вывод демонов не перенаправляется в журналы, а вместо этого это ядро, которое ловит "что-то" или собственную работу демона по управлению собственным файлом журнала.
• Я уверен, что в случае какой-то сложной ошибки я найду что-то messagesв то время как в текущем syslog там будет типичная информация ядра о завершении процесса или около того; Я мог бы еще придумать идею такого теста, чтобы показать это
• в то время как я не показал ясно, что текущая регистрация пропускает вещи, я точно показал, насколько многословно messages было