В ряде случаев возникают проблемы при запуске файла созданного средствами php

Обновлено: 15.01.2025

В этом разделе собраны наиболее общие ошибки, возникающие на этапе сборки.

Я получил последнюю версию PHP, используя анонимный доступ к Git, но в нём нет конфигурационного скрипта!

Вам нужен установленный пакет GNU autoconf для того, чтобы сгенерировать конфигурационный скрипт из configure.in . После получения исходников с Git сервера просто запустите ./buildconf в директории верхнего уровня. (Также, если вы запускаете configure без опции --enable-maintainer-mode , то конфигурационный скрипт не будет перестроен автоматически при изменении файла configure.in , поэтому вам необходимо делать это вручную, когда вы заметите, что configure.in изменился. Один из симптомов - появление таких вещей как @VARIABLE@ в вашем Makefile после выполнения configure или config.status .)

Для configure/setup скрипта вам необходимо указать директорию верхнего уровня, в которой находятся исходники Apache. Это означает, что вам надо задать --with-apache=/path/to/apache, а не --with-apache=/path/to/apache/src.

Во время конфигурации PHP ( ./configure ) вы наталкиваетесь на ошибку, схожую со следующей:

Не забудьте внимательно прочитать инструкции по установке и заметьте, что для компиляции PHP вам нужно установить как flex, так и bison. В зависимости от ваших настроек, установите bison и flex либо из исходников, либо из пакетов, например, RPM.

fatal: relocation error: file /path/to/libphp4.so:
symbol ap_block_alarms: referenced symbol not found

Эта ошибка обычно появляется, если ядро Apache было скомпилировано как разделяемая библиотека DSO (Dynamic Shared Object). Попробуйте переконфигурировать Apache, используя, по крайней мере, следующие флаги:

Для более подробной информации читайте файл INSTALL в директории верхнего уровня или » страницу руководства Apache по DSO.

Когда я запускаю configure, он говорит, что не может найти файлы include или библиотеку для GD, gdbm или какого-либо другого пакета!

Вы можете сделать так, что скрипт configure будет искать файлы заголовков или библиотеки в нестандартных местах, задав дополнительные флаги для С препроцессора и компоновщика, такие как:

Если вы используете csh-подобную оболочку (зачем?), то это будет:

При компиляции файла language-parser.tab.c мне выдаются ошибки, говорящие yytname undeclared .

Когда я запускаю make, похоже, он выполняется нормально, но на конечной линковке жалуется, что не может найти некоторые файлы.

Некоторые старые версии make ошибочно не помещают скомпилированные файлы в поддиректорию functions в той же директории. Попробуйте выполнить cp *.o functions и затем перезапустить make. Если это помогло, то вам действительно надо установить свежую версию GNU make.

При компоновке PHP, он жалуется на некоторые неопределённые ссылки.

Я следовал всем шагам по установке модульной версии для Apache на Unix, но мои PHP-скрипты выводятся в браузере или я получаю запрос сохранить файл.

В документации рекомендуется использовать: --activate-module=src/modules/php4/libphp4.a , но такой файл не существует, поэтому я заменил это на --activate-module=src/modules/php4/libmodphp4.a и оно не работает!? Что происходит?

Заметьте, что файл libphp4.a не должен существовать. Он будет создан в процессе!

Когда я пытаюсь собрать Apache c PHP в виде статического модуля, используя --activate-module=src/modules/php4/libphp4.a он говорит, что мой компилятор не ANSI-совместимый.

Проверьте три вещи. Во-первых, по какой-то причине, когда Apache создаёт Perl скрипт apxs, он получается без правильного компилятора и переменных, задающих флаги. Найдите ваш apxs скрипт (попробуйте команду which apxs), иногда он установлен как /usr/local/apache/bin/apxs или /usr/sbin/apxs . Откройте его и найдите строки, схожие с этими:

Вторая возможная проблема возникает только на Red Hat 6.1 и 6.2. Скрипт apxs, поставляемый с Red Hat, сломан. Ищите эту строку: Если вы нашли вышеприведённую строку, измените её на следующее: И последнее, если вы переконфигурируете/переустанавливаете Apache, запустите make clean после ./configure и перед make.

Во время выполнения make я очень быстро получаю ошибки и множество всяких RUSAGE_ .

При выполнении make во время установки, если вы сталкиваетесь с проблемами, похожими на следующее:

Если выдаются ошибки, то ваши include файлы испорчены.

Во-первых, важно понимать, что это Warning (предупреждение), а не фатальная ошибка. Так как это последнее, что выводится во время make , оно может выглядеть как фатальная ошибка, но это не так. Конечно, если ваш компилятор умирает на предупреждениях, (Warnings), то тогда да. Также имейте ввиду, что поддержка MySQL включена по умолчанию.

Замечание:

Начиная с PHP 4.3.2 вы также будете видеть следующий текст после того как сборка (make) завершится:

Build complete.
(It is safe to ignore warnings about tempnam and tmpnam).
(Сборка завершена, можно безопасно игнорировать
предупреждения о tempnam и tmpnam.)
Я хочу обновить мой PHP. Где я могу найти строку ./configure, которая была использована для моей текущей PHP установки?

Либо смотрите файл config.nice в дереве исходников вашей текущей PHP установки, либо, если это недоступно, просто выполните скрипт:

В начале вывода будет находиться строка ./configure, которая была использована для сборки текущего PHP.

При сборке PHP с библиотекой GD, либо выдаются странные ошибки компиляции, либо ошибки сегментации (segfaults) при выполнении.

Убедитесь, что ваша библиотека GD и PHP компонуются с одними и теми же зависимыми библиотеками (например, libpng).

При компиляции PHP я, кажется, получаю случайные ошибки, например она зависает. Я использую Solaris, если это имеет значение.

Использование не GNU утилит во время компиляции PHP может вызвать проблемы. Чтобы быть уверенным, что компиляция PHP будет работать, используйте GNU утилиты. Например, в Solaris, использование SunOS BSD-совместимой или Solaris версии sed не будет работать, а GNU или Sun POSIX (xpg4) версии sed будет. Ссылки: » GNU sed, » GNU flex, and » GNU bison.

Достаточно часто у начинающих разработчиков встречаются проблемы с запуском PHP-кода. Симптомы и причины могут быть самые разнообразные. Ниже приведены наиболее часто встречающиеся симптомы и их возможные причины.

Вы открыли страницу/файл в браузере и увидели на странице PHP-код. Возможно, вперемешку с другими элементами страницы.
Либо вместо страницы файл "скачался", а в нём Вы увидели исходный код PHP.

Для начала попробуйте выполнить тестовый скрипт. Сохраните в отдельный файл test.php следующий код (только этот код и ничего больше):

Попробуйте добавить в самое начало кода следующие строки:

Код не выполняется / не работает / выводится в браузер / пустая белая страница
php Я установил apache2 и php Написал скрипт он выводился как код, прописал sudo find.

PHP Код из Бд ( sqlite3) выводится в браузер, а не выполняется
Собственно, проблема в том, что код при подстановке из бд в файл не выполняется, а только.

Не работает редактор - взамен только пустая белая страница
При попытке редактирования материала на сайте, или при попытке создать новый материал через.

такие команды применят смену владельца и прав на доступ к папке и всем вложенным файлам

P.S. пояснения
-R - рекурсивный обход
USER - пользователь, на которого вы хотите сменить владельца (к примеру administrator, www-data, root)
path/to/dir - путь к директории
755 - права на доступ на чтение и запись

а "смена прав на доступ ВСЕГО, что в папке".
во вторых, в цифре 755 перовая цифра - права владельца, вторая цифра - права группы, к которой принадлежит владелец, и третья - права "других". при этом цифра является простой суммой из трех чисел:
4 - разрешено читать
2 - разрешено писать
1 - разрешено выполнять.

то есть, давая 4, разрешаем читать. хотим разрешить еще и писать - добавляем двоечку и получаем 6, а хотим разрешить исполнять - добавляем еще единичку и получаем 7.

таким образом - 755 это "владельцу можно все, группе можно читать и исполнять, и ЧУЖИМ (точнее, всем остальным) тоже можно читать и исполнять". В таком случае возни кает резонный вопрос - а на кой вообще всему этому еще и владельца назначать? Если ИТАК можно всем кому ни попадя читать и выполнять!?

Да и вообще, в свете "во первых" - а на кой самим файлам php бит исполнения? То есть, им права 7 - не нужны! Отнимаем единичку, осталось 6. Да и права на запись - зачем? Чтоб апач мог перезаписывать сам файлы php? Это действительно то, что нужно? Или же права на запись тоже долой? Отнимаем двоечку, осталось 4. В итоге - апач читать файлы сможет, а ни писать в них (в сам php файл), ни исполнять их - не сможет. Но и не надо ему это!

Посему на файлы (именно на файлы) - с головой достаточно прав 400

А вот на директории, увы, нужен бит исполнения, иначе в них войти будет невозможно. Но опять же - (как было в кино - "достаточно одной таблэтки!") - только владельцу! А остальным - "накося выкуси"!

То есть, на директории - права 500

Ну а теперь, "потанцуем", чтоб не вручную, а одним махом (ну, "двумя махами"):

Если у вас сайт на PHP, даже самый простой, время от времени в его скриптах могут возникать ошибки. Это может привести к различным неприятным последствиям, от некорректной работы некоторых компонентов сайта (например, формы обратной связи), до недоступности сайта целиком. Как самостоятельно распознать тип ошибки PHP и понять, что с ней делать дальше?

Этот материал поможет вам, во-первых, самостоятельно оценить ситуацию (и, возможно, даже решить ее), а во-вторых, точно ускорит диагностику и решение проблемы при обращении в службу поддержки. Самые ценные советы по устранению наиболее частых ошибок PHP, связанных с лимитами оперативной памяти, вы найдете в конце статьи.

Как обнаружить ошибку PHP на сайте

1. Встроенными средствами браузера

Если на странице сайта присутствует ошибка, в этой вкладке вы увидите код ответа 500 (“Internal Server Error”).

После сохранения файла .htaccess и обновления страницы вы сможете увидеть ошибку.

Если сайтом используется, например, CMS WordPress, то отображение ошибок можно также включить, заменив в файле wp-config.php:

3. С помощью журнала ошибок PHP

Журнал ошибок PHP можно просмотреть, например, с помощью файлового менеджера в Панели управления, открыв файл errors.log:

Также можно открыть файл с ошибками и нажать кнопку “Включить автообновление”. Таким образом, новые записи в журнале можно просматривать в реальном времени.

Расшифровка ошибок PHP

“Вызов неопределенной функции weblizar_get_options() в файле используемой на сайте темы enigma”.

Вероятнее всего, был поврежден один из файлов темы, поэтому можно восстановить только директорию темы ./wp-content/themes/enigma/ , а не всего сайта.

Что делать, в зависимости от типа ошибки PHP

Условно ошибки PHP можно разбить на 4 уровня:

PARSE ERROR
FATAL ERROR
WARNING
NOTICE

Parse Error

Возникают, если уже на этапе проверки кода интерпретатором PHP найдена ошибка. Чаще всего это синтаксические ошибка (например, пропущенная точка с запятой). Скорее всего, такая ошибка возникла в результате последних внесенных на сайт изменений.

Что делать?

1. Если вы НЕ специалист в PHP, восстановите сайт из последней резервной копии на тот момент, когда сайт работал без ошибок.

Fatal Error и Warning

Что делать?

Восстановите сайт из последней доступной резервной копии на тот момент, когда он работал без ошибок.

Notice

К этому уровню ошибок относятся различные “замечания”, суть которых обычно отображена в тексте ошибки.

Что делать?

Частые ошибки PHP и их решение

Fatal Error: Allowed Memory

Для этого найдите в .htaccess такую директиву:

Fatal Error: Out of memory

То же самое, что и предыдущая ошибка, с той разницей, что достигнут лимит памяти, заданный “снаружи”. Обратите внимание на параметр “Памяти на процесс, Мб, не более“ в условиях пользования нашим сервисом.

Для решения вопроса в данном случае, скорее всего, потребуется либо оптимизация скриптов, чтобы они потребляли меньше памяти, либо разбиение процессов на части. Например, объемную загрузку или выгрузку данных, если она упирается в данный лимит, имеет смысл производить частями.

Также в этом случае мы советуем попробовать отключить акселераторы PHP, если они у вас подключены.

Unable to allocate memory for pool

Сайтам на аккаунте не хватает выделенной на тарифном плане памяти для акселераторов PHP.

Также, например, можно отключить акселератор APC для определенного сайта, добавив в файл .htaccess корневой директории следующую директиву:

php_value apc.cache_by_default off

Обычно имеет смысл оставлять APC для использования на самом посещаемом из ваших сайтов — это позволит использовать именно на нем преимущества акселератора, не заполняя его память данными с других, менее посещаемых сайтов.

В случаях, когда акселератор объективно необходим для корректной и комфортной работы сайтов и его отключение нежелательно, напишите в службу поддержки.

Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal

Всем привет, есть небольшая проблема на моем хостинге.
Система CentOS 5.5 Apache 2.2.3

Апач запущен от пользователя apache

Файлы с сайтами лежит в домашних папках пользователей по адресу : /www/пользователь/www/htdocs
права да папки:
/www root:root 751
www/пользователь:пользователь 711
www/пользователь/www пользователь:пользователь 711
www/пользователь/www/htdocs пользователь:пользователь 711
папки и файлы с содержимым сайта пользователь:пользователь 755 и 644

Когда запускаю скрипт тестирования совместимости bitrix_server_test.php,
то он выдает:

Место на диске:

12458 Mb

Не менее 50 Мб для редакции "Старт" и не менее 150 Мб для редакции "Бизнес"

Права на текущую папку:

0711 bel-okna bel-okna

Создание папки:

Ошибка

Попытка создать тестовую папку

Создание файла:

Ошибка

Попытка создать тестовый файл

Запуск созданного файла:

не тестировалось

В ряде случаев возникают проблемы при запуске файла, созданного средствами PHP

Обработка .htaccess:

не тестировалось

Осуществляется попытка настроить обработку 404-й ошибки во вновь созданной папке

Время на создание 1000 файлов (сек):

не тестировалось

Нормальное время - до 2 секунд

Значение file_uploads:

Да

Я так понимаю, что у апача просто нет прав на запись. Если дать права 777 на папки с сайтом пользователя, и папку htdocs, то все работает.
Как быть?

Первое что необходимо сделать — это проверить права на файлы и папки в нужном каталоге. Права на папку должны быть 755, на файлы 664. Ни в коем случае не выставляйте права 777 на папки или файлы, даже на время.

В моём случае этот метод не сработал, я стал копать дальше. Нашел такой совет. в файле /bitrix/php_interface/dbconn.php установить такие константы.

define( "BX_FILE_PERMISSIONS", 0660 );

define( "BX_DIR_PERMISSIONS", 0775 );

@ini_set( "memory_limit", "512M" );

Но этого не потребовалось, т.к. эти значения уже были заданы и по идее всё должно было работать. На одном из форумов посоветовали изменить права доступа и владельца к нужной категории через консоль. Но я посчитал, что если всё до этого работало, то не нужно так далеко залазить, проблема явно была в не в этом, для Вас приведу код в котором можно изменить права доступа к каталогам и файлам через консоль. Говорят может помочь.

find . -type d -exec chmod 775 < >\;

find . -type f -exec chmod 664 < >\;

В моём случае решение оказалось куда проще. Все сайты лежали в корневой директории, один из них являлся общим ядром. Но по какой-то причине прекратился общий доступ к «главному сайту» и всё что нужно было сделать — это открыть доступ.

Поскольку сайты на учётных записях закрыты процессы, запущенные на одном сайте, не имеют прав для обращения к каталогам, выходящим за пределы этого сайта. Для доступа из окружения веб-сервера потребуется открыть общий доступ к каталогу. Мой проект находится на beget и эта операция делается очень просто через файловый менеджер.

Зайдите в нужную директорию
В верхней части экрана нажмите на кнопку “Инструменты” -> “Настроить общий доступ к текущей директории”:
Установите переключатели “Чтение и запись” и “Включая вложенные папки”, нажмите кнопку “Открыть доступ”:

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

Читайте также: