В настоящее время я использую безголовый сервер Ubuntu 10.04. Установлен стек LAMP, Joomla, Virtualbox, phpvirtualbox, webmin и proFTP. Он разрешает IP-адрес, поэтому я могу получить к нему удаленный доступ (либо веб-сервер apache2, либо FTP) с помощью DDClient. Все установленные пакеты были установлены с помощью apt-get. Webmin, хотя и не рекомендуется в Ubuntu Server, в основном используется для администрирования аспекта веб-сервера. Эта проблема также появилась, когда я использовал Ubuntu Server 10.10.
После периодов интенсивного сетевого трафика, локального или удаленного, соединение разрывается. Я говорю конкретно о передаче файлов через FTP, SCP или Samba (последнее я использую редко). Нет ответа на ping или ssh. Я не могу подключиться к серверу по FTP и не могу загрузить веб-сайт. Бывают случаи, когда сервер был включен в течение нескольких дней, и все работает нормально, потому что я не обращался к нему много, если вообще (следовательно, небольшой сетевой трафик).
Я претерпел несколько изменений оборудования, хотя не думаю, что это было причиной проблемы: это происходило задолго до того, как я внес какие-либо изменения. Сначала я подумал, что это мой маршрутизатор, предоставленный провайдером, блокирует трафик из-за какой-то неправильной конфигурации (возможно, предполагая, что это была какая-то DoS-атака). Я сменил роутеры и все еще не нашел успеха. Я проверил syslog, dmesg и kern.log на предмет предупреждений, но не обнаружил ни одного. Я запустил memtest через меню GRUB2 при загрузке, и как только он обнаружил 4 ошибки. Я снова запустил отдельные палки ОЗУ в разные слоты, и все оказалось нормально. Я просмотрел настройки BIOS, все в порядке. Я пробовал отключить ненужное оборудование (другие внутренние жесткие диски, приводы компакт-дисков, дискеты, карты PCI и т. Д.).
Любая помощь или советы о том, как я могу даже начать устранение неполадок, были бы очень признательны. Обратите внимание, что я только начал играть с серверами в качестве хобби, поэтому мои знания не будут самыми точными. Мне комфортно работать с командной строкой, и у меня есть инициатива, чтобы знать, как найти то, что я не могу сделать. К сожалению, я не могу найти подобных проблем.
Дополнительно: если решение не может быть найдено, некоторая помощь в написании сценария, который заставит сервер автоматически перезагружаться, если по прошествии x минут он не получит ответа на пинг где-нибудь, например, в Google. По общему признанию, это не самое чистое решение, если мой интернет выйдет из строя, но я не могу думать, что еще делать.
Если сервер полностью завис на 100%, то сценарий автоматической перезагрузки может не помочь: если перезагрузка не произойдет до зависания, вы застряли, поскольку зависание, скорее всего, повлияет на любой процесс, предназначенный для вызова сценария перезагрузки.
Обычная перезагрузка через cron может поможет, если он настроен достаточно регулярно, чтобы срабатывать до любого зависания, но это будет лечить симптомы, а не причину. Вы можете запустить перезагрузку с другого компьютера (если он обнаружит, что сервер перестает отвечать), но для этого, вероятно, потребуется покупка оборудования в виде блока питания / контроллера, который можно переключать с одной машины, чтобы заставить другую выключить и снова включить цикл питания.
Я бы порекомендовал установить какой-то инструмент мониторинга и проверить, что происходит непосредственно перед зависанием (т.е. непосредственно перед тем, как новые соединения перестанут приниматься). Я использую collectd (со специальным сценарием CGI для графического отображения записанных результатов) для общего мониторинга, хотя есть несколько других популярных вариантов. Запуск такого инструмента мониторинга с настройками по умолчанию (мониторинг использования ЦП, использования памяти, дискового ввода-вывода, показаний температуры и т. Д.) Поможет вам обнаружить очевидные вещи, такие как внезапный всплеск активности ЦП (который может указывать на плохой сценарий или DoS-ситуация) или постепенное использование памяти / подкачки (что может означать утечку памяти где-то или, в случае Apache и аналогичных служб, конфигурацию распределения рабочих, которая не подходит для размера машины), внезапное повышение температуры (что может означать проблемы с циркуляцией, плохая вентиляция или другие внешние условия окружающей среды, являющиеся частью проблемы) и т. д. Если выявлена общая проблема, подобная этой, вы можете добавить более подробный мониторинг, чтобы сосредоточить внимание на более конкретной причине.
Также установите и настройте smartd, если вы еще этого не сделали. Это может помочь отследить проблему, если она связана с накопителем, на котором возникла (или уже есть) серьезная проблема.
В любом случае проверьте обычных подозреваемых в / var / log после зависания - вы можете обнаружить, что некоторые подсказки записываются в таких местах, как / var / log / messages и / var / log / syslog (или аналогичные), непосредственно перед тем, как машина перестает отвечать. . Если на самой машине ничего не останавливается при сбое удаленных подключений, возможно, у вас неисправная сетевая карта, которая зависает (но оставляет остальную часть машины в порядке) и остается в этом зависшем состоянии до тех пор, пока машина не будет перезагружена или выключено и выключено.
Более конкретно: ваши тесты RAM, показывающие некоторые ошибки в одном или двух случаях, скорее всего, вызывают либо RAM, либо охлаждение. У вас может быть некоторая "немного" хитрая RAM, которая обычно работает и проходит тесты, но очень иногда переворачивает биты и вызывает проблемы, или у вас может быть проблема RAM, которая чувствительна к температуре (все в порядке, пока температура не достигнет определенной точки), или она может быть более общая проблема с нагревом / охлаждением. Ваш ЦП или другие основные микросхемы также могут испытывать проблемы с нагревом, что приводит к аналогичным периодическим эффектам.
Аналогичная проблема с Apache / PHP на RHEL5.x: зависание и доступ к консоли / ssh невозможны. В журнале / var / log / messages сообщается, что "[...] httpd вызвал oom-killer [...]"
Решение заключалось в добавлении памяти, включении KDump с panic_on_oom и создании более подходящих ограничений для процессов Apache / PHP. С тех пор проблем нет. KDump с panic_on_oom автоматически перезапустил систему, предотвращая зависание. Однако реальное исправление ограничивало Apache / PHP. По умолчанию, особенно. для PHP были слишком широко открытыми и небезопасными. Существует множество онлайн-ресурсов по защите PHP, поэтому я не буду пытаться воссоздать их здесь.
Возможно, это не причина для вас, но я некоторое время наблюдал это в 10.04 LTS при использовании dhcp. Однако, если установить адрес интерфейса как статический, проблема исчезнет.
Я знаю, что это была проблема с 10.04 LTS, потому что я видел, как это происходило по крайней мере на 1 ПК и 2 серверах с сетевыми адаптерами Intel. Я также должен отметить, что эта проблема, похоже, решена для меня с последней сборкой сервера Ubuntu 10.04 LTS. Я считаю, что это сборка 3 или 4 из этого.
https://askubuntu.com/questions/102910/ubuntu-server-10-04-lts-xen-intermittent-networking
На данный момент убедитесь, что вы не используете DHCP для назначения адреса, даже если DHCP-сервер настроен так, чтобы всегда выдавать один и тот же адрес. Скорее установите его статически в / etc / network / interfaces
Я считаю, что это может быть связано с тем, что службы сильно нагружают ваши системные ресурсы. Другое возможное решение может заключаться в том, чтобы посмотреть, сколько возможных подключений вы можете иметь к вашему веб-серверу и / или сколько хостов могут использовать маршрутизатор.