netfilter "kernel: printk: x message suppressed"
GNU/Linux, UNIX, Open Source → *BSD и другие системы
Добрый день.
Работаю на RedHat,(ядро 2.6.9). Есть несколко апликух (серверных), которые стоят на этой системе. Несколко дней все нормально работает. Потом клиентские проги уже не могу залогиниться на сервере. Все подключения на сервере переходят в статус SYN_RECV. Потом в CLOSE_WAIT. Собственно, ip_conntrack_log_invalid был установлен в 6, чтобы невалидные тсп-ишные соединения логировать. Тогда в /var/log/messages появляются строки такого вида:
kernel: printk: x message suppressed
где х — различные числа.
Насколько я понимаю, встроенный в ядро netfilter определяет исходящие пакеты как невалидные? Как можно получить большую инфу об этих пакетах? Хм…может эти логи пистаь функция send, если обнаруживает ошибку, например, в дескрипторе сокета. Потому что в логах серверной апликухи иногда проскакивает «Bad file descriptor"? Может, есть возможность узнать, какое приложение инициировало запись логов? Вообщем-то, если не трудно, поделитесь опытом, как еще можно выудить полезную инфу из этой ситуации.
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
kernel — это и есть автор записи в логе.
Я это понимаю. Там и написано английским по белому :). Имеется ли возможность определить источник? Кто заставил «аффтара» написать это.
К сожалению, в интернете на эту тему нет инфы. Я нашел кучу описаний, как справиться с
printk: x message suppressed
Но. Везде, где это описано наряду с этой строкой выводятся еще строки, которые показывают дополнительную информацию. К примеру, там overflow какого-нибудь стека (это я образно), а потом, мол, message dropped и suppressed. Тогда без проблем. Меняем там нужный параметр и все пашет. Но в моем случае, вообще ни единой строчки инфы, кроме того, что сообщение подавлено. Вот в этом и суть.
ipv6 попробуй отключить, если включен.
Нет, ничего не меняет.
Я тут немного в коде полазил. Странно. Это сообщение пишется с помощью вызова net_ratelimit (LOG_INVALID_PACKETS). Куча мест, где он(a) вызывается. Но везде после вызова стоит printk, который дописывает инфу, о причине. У меня же пусто…