Я имел ввиду ситуацию, когда у хостера не один сервер. К тому же, по крайней мере в моей практике, цикл заселения сервера клиентами всяко меньше цикла мажорных изменений в ПО.
И, кстати, факт, что удержать клиента дешевле, чем привлечь нового.
amso добавил 14.09.2008 в 02:57
Это, опять же, хостер может и должен подсказать. Internal Server Error вряд ли с оптимайзером связан.
Был апгрейд или даунгрейд версии?
Хостера мог кто-то из клиентов на этом же сервере попросить обновить оптимайзер, или это он сам обновил php и оптимайзер за одно.
У новых версий оптимайзеров есть ряд проблем со старыми версиями php, вролне могло быть, что полгода на сервере проработала, например, 3ая ветка оптимайзера на php 4.x.x, проявились проблемы и хостер прикрутил 2ую ветку, апгрейдить php было бы больнее клиентам.
Это хостер только скажет, возможны оба варианта, зависит от того, может ли хостер сопровождать серверы с устаревшими версиями софта, даже при том, что с августа команда php свернула обновления для 4й ветки, не считаю, что для этого нет технической возможности.
amso добавил 14.09.2008 в 00:42
Кстати, свой php в cgi спасает от такого только, если он слинкован статически, иначе все равно есть зависимость от сторонних библиотек, которые хостер может в один прекрасный момент обновить.
make rmconfig && make
libtool не причем
Так ТС совсем запутается.
Zaqwr, эта цитата объясняет, зачем нужна ЕСС, то есть коррекция ошибок
Про регистровую память:
Или другими словами - буфер с путями к данным в модуле позволяет быстрее их достать, и чем больше данных в модуле, тем больше прирост скороси отдачи этих данных относительно unregistered памяти.
Про порог в 4GB я слышал и от поставщика, к сожалению, сейчас нет возможности расспросить детально.
Вообще, Ваш скрипт эквивалентен простому
Он выполняется от рута, поэтому менять владельца не нужно, проверять директорию тоже вобщем-то не обязательно
К указанному скрипту они не имеют отношения, тут источник ошибки команда find.
Проверьте, есть ли в кроне еще есть задания, которые складывают вывод ошибок в
И зачем туда? Эта директория используется кроном для файлов очереди
Попробуйте отправить вывод ошибок в другой файл, например, в /var/log/cron.err и смотрите, что будет там
либо Вы указали неполный код скрипта, либо ошибка в работе какого-то другого скрипта.
“find: rm Terminated by signal 13” - ошибка с организацией конвеера
по тексту ошибки - где-то в скрипте у Вас есть команда 'find', вывод отправляется на 'rm', вот там скрипт обламывается, проблема может быть и в синтаксисе, и в путях.
еще учитывайте, что для крона лучше указывать везде полные пути, а не относительные, либо делать переход в директорию скрипта, так как крон стартует скрипт, находять в домашней директории, а не там, где скрипт
по цитате:
Перед последней скобкой должен быть пробел
http://en.wikipedia.org/wiki/List_of_content_management_systems
Ну, элементарно могла быть ситуация, что ответивший Вам не в курсе каких-то там договоренностей ранее. С чистого листа запрос выглядит компромитирующим. Лучше приложить к письму инфу, которая бы подтвердила, что клиент делегировал Вам полномочия на работу с доменом
Тестов не проводил, но из описания работы модуля оно так и следует. Дополнительный тик присутствует, но буфер его компенсирует и на большом объеме данных в модулях добавляет производительности.
Upd. А вот в указанной статье в википедии есть ссылка на фак.
А Вы указывали в запросе какие-то реквизиты, подтверждающие то, что Вы имеете отношение к домену? Ответ хостера, конечно, вне рамок делового такта, но если письмо с запросом было именно таким, то выглядит оно просто как соц. инженерная попытка увести домен.
