ipchains и логи

Посмотри, что у тебя в /etc/syslog.conf нарисовано на тему сообщений ядра. Должно начинаться на kern.* и если сообщения на экран сыпятся, то там у тебя должно быть что-то вроде /dev/console. Закомментируй.

barmasay
ДыК в том то и дело, что в сислоге все нормально
(#kern.* /dev/console - под комментом)
И строки-то лезуть не всегда!!!
Но я заметил, что вроде как такая фигня бывает после сбоев.
При этом в логе строки приблизно такого содержания:
======================
kernel: Unable to handle kernel paging request at virtual address 412cac04
kernel: current->tss.cr3 = 00783000, %cr3 = 00783000
kernel: *pde = 00000000
redhat62 kernel: Oops: 0000
kernel: CPU: 0
kernel: EIP: 0010:[__free_inodes+26/104]
kernel: EFLAGS: 00010a97
kernel: eax: 07f2bfdf ebx: 412cac04 ecx: c398da90 edx: c2670770
kernel: esi: 412cac04 edi: 00000807 ebp: c1ce9ea8 esp: c1ce9e70
kernel: ds: 0018 es: 0018 ss: 0018
kernel: Process smbd (pid: 9043, process nr: 79, stackpage=c1ce9000)
kernel: Stack: 00008164 00000807 c0133ee2 c1ce9ea8 fffff7c9 00000807 00000000 c1ce9f5c
kernel: 00008164 c2adc000 c37312a0 c2c3980a 00001c4d c012855b c2670778 c3ba4338
kernel: c0133f3e 00000807 00000000 c1ce9f5c 00008164 c2adc000 c0d227c0 0000004d
kernel: Call Trace: [try_to_free_inodes+210/264] [__brelse+19/84] [grow_inodes+30/384] [get_empty_inode+141/152] [ext2_new_inode+49/1728] [do_follow_link+120/132] [ext2_create+35/380]
kernel: [open_namei+361/848] [filp_open+68/248] [sys_open+54/148] [system_call+52/56]
kernel: Code: 8b 36 8b 43 14 0b 83 80 00 00 00 75 e9 8b 03 8b 53 04 89 50
=========================

Что это было? И где мои вещи?...

Что это было - не знаю. У меня с Ipchains таких проблем не возникало.
Но с iptables было, логи тоже валились на консоль, но в iptables
можно установить уровень логирования, это и решило мою проблему.
По аналогии могу предположить, что когда к тебе с запрещенных адресов
идет слишком много пакетов, syslogd как бы не успевает их записывать в messages,
и потому кидает на консоль. Попробуй эти адреса закрыть на циске.
В приведенном тобой логе мне не нравится вот это:
kernel: Process smbd (pid: 9043, process nr: 79, stackpage=c1ce9000)
То ли тебе самбу пытаются завалить?

>>То ли тебе самбу пытаются завалить?
Я думаю нет. У меня есть еще штук 5-6 таких примеров.
Там в качестве "процессов" присутствует все что угодно. Хрен его знает как ядро виновника отбирает. Может кто под раздачу попадет - того и пишет в лог?..

Я больше боюсь, что это с железом связано. Конкретно с винтом или контроллером. А как проверить?.. Хрен... Нет у меня толковой программульки:(
Был у меня с месяц назад сбой. Подвисло все намертво. А после перегруза один раздел отказался автомонтироваться.

А может стоит ядро попытыться перекомпилить? Страшно конешно оно... Может поможет...А?...

А насчет Циски - спасибо, конешно. ДыК только ее надо иметь шоб было где закрывать:)

неплохо-бы fsck сделать в первую очередь. потом посмотреть внимательно в настройки железа. но то что данные ошибки имеют малое отношение к чейнзам, это почти точно. крайне похоже на неправильную настройку дисковой подсистемы или банальные ошибки в ext2.

Спасибо всем, кто проявил участие в моей проблеме.
Все оказалось (надеюсь!) проще.
После того, как пошли "улеты" при компиляции программ (sigh11) - я заменил модули памяти и ... тьху-тьху чтоб не сглазить - пока все нормально.