Linux.by

Сломал мозг... Один раз в день, в период с 9.30 до 11.00(каждый день время разное), сервер на Debian lenny начинает отказывать в соединении по портам 80, 3128, 22, 110, 25 и т.д. на обоих интерфейсах (интернет и локалка). При этом пинг проходит, текущие сеансы ssh обрывает, проксик соответственно отказывает в соединении. Cron проверил, вроде ничего подозрительного. Помогает вынимание сетевого шнура, либо ожидание. То есть проходит определенное время(от 2 до 10 минут) и все начинает работать. В syslog, messages, kern ничего подозрительного. Поражает отсутствие логике во времени возникновения проблемы. Если бы задание по cron, то было бы в одно и то же время. Может быть есть у идеи куда посмотреть?

Установи sysstat и понаблюдай за нагрузкой на сервер. Что говорит tcpdump при попытке соединяться на порт?

tcpdump можно посмотреть только физически в серверной, а когда вылезает проблема стараюсь поскорее решить, а не смотреть на экран. Завтра поставлю tcpdump писать в файл, посмотрим.
Во вложениях график sysstat из webmin по локальному и внешнему интерфейсу.
Во время обрывов линии в графике, связь не теряется. Может systat глючит.

Разрывы в графиках могут говорить о слишком высокой нагрузке в этот момент. Ты покажи LA в эти моменты.

Разрывы есть на всех графиках, вот для примера графики cpu, load, eth1.
К тому же, повторюсь, такие разрывы в графики идут все время, но связь не обрывается при этом.

Что за сетевуха и дистрибутивное ли ядро. Если помогает передергивание кабеля, то вероятно что-то творится с модулем сетевухи... Часом не attansic одна из них?

ядро из коробки 2.6.18-6-486. обманул,я вас, Etch у меня там, сорри.
Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
Проблема появилась после 2 месяцев функционирования сервера.

Посмотрите внимательно логи на предмет сообщений conntrack.
Примерно вот таких: ip_conntrack: table full, dropping packet.

Во время отказа соединений со своего компа сделай nmap -sP на айпишник данного сервера. Возможно ты удивишься, сравнив его с реальным маком сервера.

Господа, простите за некропостинг...
У мены проблема 1в1, вам удалось её решить?
Я в логах наткнулся на "странные" действия крона...
как мне показалось совпадающих с обрывами связи...
Сейчас буду мониторить сервак на эту зависимость...

cat /etc/crontab

Закоментил строку с "17 ..."
Вот уже 12 часов как сбоев не было, мониторю...

Нет, никак не связано.
У меня на порту 5000 работает БД, при обращении на него тут же рвется коннект.
Теперь нужно понять почему?
Ситуация сл:
на компе стоит Ubuntu (мой рабочий), из под убунты подключаюсь к БД админской софтяриной, всё ок. порт тот же.
Из под VirtualBoxа с WinXP подключаюсь к это БД на этот порт, коннект рвётся.
Возможно хитрож.пая Debian как то сравнивает MAC адреса сетевухи и то что с неё с разных IP приходят пакеты и рвёт связь?

Интересно. У меня такая же проблема.

Ubuntu Server 10.04 LTS. Сервер создан для хранения на нем больших массивов данных, создан RAID1, установлена Samba, открыт общий доступ. Круглые сутки к серверу подключено 2-8 клиентов.

Сервер периодически (до этого это случалось 1-2 раза в день, сегодня случается чуть ли не каждые 5 минут) закрывает все соединения с собой, будь то samba-сессия других работников, или моя putty-сессия - рвется все.

Где-то месяц назад такое уже было. Тогда я думал, что это происходит по причине каких-то конфликтов между этим сервером данных и контроллером доменов (Win2003), в котором сервер данных был прописан в списке DNS. Тогда я просто удалил убунту из списка DNS, она перестала быть видна в списке компьютеров домена, но зато связь стала стабильной.

Пару недель назад все началось снова, но теперь я никак не могу найти причину сбоев. Сервер с завидной постоянностью рвет соединения, с ним просто невозможно работать.

Что я пробовал делать:
- обновлял систему и ядро (есть предположение, что проблема в ядре. Хотя, сейчас уже точно ясно, что с ядром все в порядке..)
- комментировал строку с "17.." в /etc/crontab
- перезагружал сервер, менял настройки самбы (вначале думал, это из-за неё)

Сетевой интерфейс настроен просто и без изысков. Напутать там что-либо просто невозможно: eth0, плюс локалхост, больше ничего.

ahmed90, с вероятночтью 95% - конфликт IP-адресов.