Здесь мы перешли со Slackware на CentOS, тогда он работал нормально без предварительного уведомления, php перестал выполнять внешние вызовы, такие как вызовы «wc» и «spamc». Все такие вызовы появляются в error_log как:
sh: / usr / bin / spamc: В доступе отказано
Пути правильные. У нас правильно установлены разрешения, и предполагается, что apache сможет без проблем выполнять файлы. Мы НЕ на safe_mode, и у нас нет установленного base_dir. Это не SELinux, или, по крайней мере, в sestatus говорится, что SELinux отключен.
резюме:
Версия PHP 5.3.3 и CentOS 5.5
Кто-нибудь знает, что может происходить? заранее спасибо
Нашел ошибку.
Например, я пытался выполнить / usr / bin / tidy, у папки usr было разрешение 644, что сродни лавкрафтовскому ужасу в моей книге. Я мог работать, потому что был root.
Я понял это после того, как сошел с ума и решил проверить разрешения для всех компонентов пути команды от корня / папки до аккуратного двоичного файла, я обнаружил, что все разрешения установлены правильно, но разрешения папки usr были полностью завинчены.
Это исправлено.
Это хиты разрешений ... имейте в виду
«Permission denied» может быть где угодно по пути, а не только файл, который вы вызываете. Так что посмотрите также на "/ usr / usr / bin" и "/".
Это также может быть связано с тем, что php не скомпилировал что-то, что ему нужно. Можете ли вы включить strace и попробовать еще раз?
для этого вам нужно будет остановить / запустить apache / exim (или что-то еще) с включенным strace:
strace -f -o trace.txt /etc/rc.d/init.d/servicename start
Обычно это apache, кстати
strace -f -o trace.txt /etc/rc.d/init.d/httpd start Теперь просто попробуйте снова запустить функцию
Поскольку опция «-o» сохраняет результат в файл «trace.txt», давайте посмотрим @ этот файл:
cat trace.txt | grep "/usr/bin/spamc"
Это должно позволить вам увидеть гораздо лучший журнал и намек на то, что происходит.
Убедитесь, что вы отключили эту повязку, иначе журналы станут очень большими.