chroot Apache+MsSQL на openBSD; Не удалось определить полное доменное имя сервера
php генерирует GIF-файлы на веб-сервере, используя базы данных на втором сервере. На странице показано 20 GIF-файлов, поэтому некоторая загрузка происходит в течение короткого времени (несколько подключений)
Некоторые GIF загружены, но некоторые нет, в /var/www/logs/error_log
[Понедельник, 23 февраля 10:05:56 2009] [error] Предупреждение PHP: mysql_connect() [function.mysql-connect]: потеря соединения с сервером MySQL при "чтении исходного пакета связи", системная ошибка: 0 в /htdocs/.../myImage.php в строке 4 [Понедельник, 23 февраля 10:05:56 2009] [ошибка] Неустранимая ошибка PHP: потеря соединения с сервером MySQL при "чтении исходного пакета связи", системная ошибка: 0 в /htdocs/.../myImage.php в строке 4
в /var/www/logs/error_log на сервере MySQL я нашел:
[alert] httpd: не удалось определить полное доменное имя сервера, используя 127.0.0.1 для ServerName
Перезагрузка сервера MySQL "решает" проблему... в течение нескольких дней.
Эти 2 сервера являются виртуальными машинами, работающими под управлением OpenBSD, Apache с поддержкой chroot и MySQL + phpMyAdmin. к сожалению, в разных версиях (OpenBSD 4.2(web) и 3.9(mysql))
мои знания в /var/www/conf/httpd.conf а также my.cnf(не нашел) очень ограничен.
Есть идеи?
2 ответа
Вы пытались поместить resolv.conf внутри chroot? Такие как:
mkdir -p /var/www/etc/ && cp -p /etc/resolv.conf /var/www/etc/
Вы также можете сделать то же самое для /etc/localtime, если обнаружите, что время вашего веб-сервера отключено от вашего часового пояса.
Замечания:
- не используйте ссылку sym, потому что она не будет работать через chroot
- не используйте жесткую ссылку, потому что изменение файла в chroot приведет к изменению файла в /etc!
Ошибка "Не удалось определить полное доменное имя сервера" можно игнорировать, это внутренняя проблема apache.
По http://dev.mysql.com/doc/refman/5.0/en/error-lost-connection.html и http://bugs.mysql.com/bug.php?id=28359 это звучит как медленный сеть, или перегруженный MySQL, который не может ответить на соединения достаточно быстро.
Учитывая, что перезагрузка устраняет проблему, я предполагаю, что у вас медленная утечка ресурсов. Вероятно, что-то вроде дорогих запросов осталось работать на MySQL. Вы должны быть в состоянии проверить это, отслеживая загрузку системы с течением времени.