Прогресс - зло!

Потерял полдня, прежде чем сложил все кубики в пирамидку (и то, не уверен что правильно).

Нужно: получить PHP5 с клиентом PosgreSQL (всякие прочие extensions на вырост), в виде апачевского модуля, все происходит под FreeBSD7.

  • Apache 1.3, все собираем из ports - не работает. SIGSEGV где-то внутри инициализации pthreads, хотя никому из участников эти threads нафиг не нужны и непонятно кто их приволок. /usr/local/bin/php - работает.
  • Apache 1.3, собираем PHP --with-pgsql - все работает, пока нет загружаемых extensions. Как только появляется хоть одно - падаем.
  • Apache 2.2, собираем все из ports - работает.
  • FreeBSD6 в этот раз не пробовал, но когда в прошлый раз пробовал - работало.

Получается, из-за скромненькой фигулинки всем проектам показан переезд под Apache2 ? И mod_perl2 ? А mod_perl2 небось тоже не работает ?

MySQL не предлагать. С Apache я совладаю как-нибудь, а два сервера баз данных в моей жизни - это уже перебор. Снести семерку тоже не предлагать, UFS2 на терабайтных FS - уже перебор.

Comments

собираем русский апач не из портов
собираем модуль php5 из портов
собираем к php5 пострексный клиент из портов

так работает?

Понятия не имею, но думаю что нет.

Русский апач от просто ports/www/apache13 в этом месте не должен отличаться

uname -a
FreeBSD gk 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Mar 26 19:56:25 MSK 2008 slw@gk:/usr/obj/usr/src/sys/GENERIC i386

Server Version: Apache/1.3.41 (Unix) PHP/5.2.5 with Suhosin-Patch rus/PL30.22<br>
Server Built: Apr 11 2008 21:46:22<br>

php.info.php: <?php print_r (get_loaded_extensions()); ?> =>

Array
(
[0] => standard
[1] => Reflection
[2] => date
[3] => libxml
[4] => apache
[5] => pgsql
)

Да Макс написал уже, что дело скорее всего в mhash

Сейчас изучу это место окончательно и расскажу.

пока в России думают о переходе на 2 апач:
1) во всем остальеом мире его уже давно используют
2) насколько я понял уже пишут apache 3

первый апач - работает, это большое достижение. Износу нет.

Второй - слишком долго не работал :), а в моем случае тянет за собой переписывание довольно большого количества legacy-кода. Переписывание скорее всего банальное (вместо use Apache; - use Apache2), но у меня новому дизайну lexa.ru уже около 10 лет, коду под ним - примерно столько же.

Так я против 2-го апача ничего не имею, просто относительно свежие сайты я понимаю как перевести, а про www.lexa.ru даже думать страшно.

Одним use Apache; - use Apache2 не обойдется
в Apache2 очень сильно переделано обращение к мод-перловому функционалу.
Одно получение $r чего стоит:
my $r = Apache2::RequestUtil->request();

фрюха - это по определению ?

Да, речь идет о сайте под новый проект, это потянуло за собой Drupal (на MovableType все-таки много не хватает), Друпал потянул PHP (много лет обходился).

Но менять сервер БД/заводить второй (MySQL) - уже перебор. А переставлять ОС-ы на серверах - тем более.

Собирая apache13 из портов - убедись, что у тебя не прилетел php-шный extension mhash. Он использует libmhash, который в свою очередь собирается с -pthread и подцепляет libthr.so. Как результат - SIGSEGV, ибо сам апач без тредов.

Правильным фиксом наверное будет отрубить -pthread при сборке libmhash, ибо оно ему нафиг не надо (а если кто-то использует из тредового приложения - то отткуда libthr и подцепится), но руки пока не дошли. Просто выкидываю из extensions.ini и живу счастливо.

С pgsql я не игрался, всё больше на mysql, но общий вид граблей до боли знаком.

О. Очень похоже, что это именно оно.

Опробую - доложу.

Не-а, не лечит.

Там если присмотреться, почти все собирается с pthreads и PHP и postgresql-client. А не работает (помимо выкинутого mhash) именно постгресовый экстеншн, даже сам по себе (остально все из .ini выкинуто).
Причем - не работает - это coredump на старте, еще до первого запроса.
Валится внутри gethostbyname т.е. если запустить без этого экстеншена,
а потом переконфигурировать, то даже может поработать.

Собрать что-ли апач с pthreads :)

Но я уже смирился с мыслью о постепенном переезде под 2.2

если собрать -- работает
Array
(
[0] => standard
[1] => Reflection
[2] => date
[3] => libxml
[4] => apache
[5] => pgsql
[6] => mhash
)

Сам PHP ни разу с pthreads не собирается, это ты плохо присмотрелся. А вот postgresql-client - похоже что таки да. Лечить, всех лечить.

Поддерживать свои патчи к ports/*/*/Makefile - еще дороже, чем один раз переехать на apache 2.2

Я это место, конечно, полечу ради прикола (но не для продакшена), но вообще все казлы!

Я, право слово, не предлагаю поддерживать свои патчи. Репозиторий FreeBSD не является неприкосновенным. :)

Оптимально было бы вылечить проблему совсем, чтобы было пофиг как собирать - но судя по всему не получится. Значит будем править порты так, чтобы thread-aware библиотеки собирались без -pthread. Ибо именно для этого в libc есть заглушки на pthread_*.

А данная конкретная проблема легко лечится методом "make PTHREAD_CFLAGS= PTHREAD_LIBS=" при сборке postgresql-client.

Ага, собирать клиента без threads, а потом молиться, чтобы никакая тредовая программа его не поюзала.

Конкретная проблема с pgsql, похоже лечится тем способом, что Друпаловские модули (3rd-party) о постгресе вообще не думали, когда писали (ругань на формат даты), да и в Drupal Core с постгресом работает не полностью (OpenID-авторизация работает, но что-то в базу записать не может).

Поэтому новая тема - загнать весь друпал в jail или на виртуальную машину и пусть там и живет вся эта теплая компания - Mysql, PHP, Apache 2.2 (если они без него не могут)

> Ага, собирать клиента без threads, а потом молиться, чтобы никакая тредовая программа его не поюзала.

Ты не понял. Библиотека, которая _не_создаёт_ треды сама, а использует только pthread_mutex_lock() и прочее для блокировок - должна собираться без -pthread. Тогда в приложении без тредов она будет использовать заглушки из libc, а в приложении с тредами - вместо заглушек подберутся реальные функции из libthr.so. И все в шоколаде.

Проблемы наступают только тогда, когда библиотеку собрали с -pthread, хотя ей это нафиг не нужно, а используют из не-тредового приложения. В результате внутри этой библиотеки зовутся реальные функции из libthr, а во всей остальной программе - пытаются использоваться заглушки из libc.

а если ей это нужно, но зовут ее из нетредового приложения?

Чудес не бывает. Если библиотека создаёт треды - то и приложение должно быть тредовым.

лечится апачевый Configure на сборку с -libpthread и после этого все работает.
судя по аналогичным строчка для аикса и сопляриса -- это штатный способ.
дльше либо send-pr либо так и оставить -- я апачу из портов не собираю.
мне их раскидывание по каталогам не нравится.

после этого -- работает, я проверил

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

Что до AIX'а и Solaris'а - там есть Thread Process-Shared Synchronization, и апач собирается с -lpthread чтобы его использовать для accept mutex'а. Не наш случай.

О, слово знакомое увидел - Друпал. А какой друпал (версия)? Просто будет у кого поспрашивать если что.

Наисвежайший. А спрашивать я у тебя буду, а не наоборот

Свежайший, говоришь? Мда.... страшненько на него переежжать.

Давеча в три ночи сижу в офисе, вожусь с программой понятно чего, вдруг gmail булькнул и говорит: Security advisor Drupal Сore ver... а дальше не видно, вот пока я мышку переводил - холодным потом покрылся, только бы не пятерка - пронесло - на 6.1 наехали. А так - апгрейдить его часа на 4ре наверное занятие.

Так что я пока на пятерочке посижу, хотя после КИБа поставлю, посомтрю на 6.2

И еще - пока я с ним ковырялся- встречал пару модулей у которых в потрохах написано - тока для mysql. Просто предостережение.

ах ты блин, а нафига собирать <b>апач</b> с --with-pgsql ?!

Это PHP, не апач.

ну хорошо. зачем <b>php</b> так собирать?!

я надеюсь ты php из портов собираешь?

Блин, если собирать из портов, а потом собрать php5-extensions (включая mhash, см выше) - то куку.

Если собрать не из портов, но --with-pgsql - то работает. По дурному стечению обстоятельств, extension который я тестировал был именно mhash - от него опять рушицца.

UFS2 на терабайтных FS - уже перебор.
Понимаю, что оффтопик. Судя по этим словам -- ZFS? И как оно тебе? Я, похоже, нашёл бюджет на 5x500Gb + коробка под них, и вот теперь мучительно выбираю между FreeBSD 7.0 + ZFS/zraid и FreeBSD 6.x + geom_raid5... Слишком как-то много крику про нестабильность ZFS...

У меня ZFS давно работает на рабочей станции, мне нравится. Поставил вот на домашний сервер (3x500 на RAIDZ), пока тоже работает.

Других данных пока нет.

Что смущает в ZFS -- это полное непонимание того, как оно работает.
Я был на официальных курсах Solaris Internals -- там была лабораторная "вытащи данные из USF руками". Автор курсов и лектор признался, что уже год пытается сделать такую для ZFS и не может, так как структура очень сложна :)

Я и с UFS не могу, поэтому мне без разницы. Бэкапы спасают.

ZFS довольно быстрая и пока не разваливалась.

Я кстати тут тоже нарвался на подобную проблему по 7 фрей...
Собрал 2.2 апач - он падает, отключил тридс и пересобрал и он заработал...
Потом собрал php5 с расширениями - падает...
Отключил все расширения - стартует нормально...
Методом исключения нашел, что падал из-за расширения php5-imap...

А чего плохого в UFS2 на терабайтных FS? :)

многочасовой fsck

Так он же токо при старте... пусть себе проверяет :)

После нехороших падений (вроде ресета по питанию) fsck может идти часами.

Что жутко неудобно, если на сервере какая-то важная для бизнеса задача.

а gjournal?

Чтобы у журнала была нормальная скорость записи - его нужно на отдельном массиве собирать.

Add new comment