Не работает exec() на FreeBSD

[sanych]

Не работает exec() на FreeBSD

Делаю сайт на локальном хосте (Kubuntu Linux, Apache 2, PHP 5.2.6), в скрипте использую вызов приложений ffmpeg и mencoder (для конвертации видео и вытягивания картинки из видео). Локально все работает. Залил на сервер (FreeBSD, Apache 2, PHP 5.2.8), там не работает.
Дальнейшие действия:
1. Использовать shell_exec вместо exec. Не работает.
2. Проверил safe_mode = Off
3. Зашел по SSH на сервер под рутом и ввел в командную строку точно такую же команду как в скрипте (строка в точности такая же) - так сработало. Но из скрипта не хочет.
4. Папки, в которые должны попасть выходные файлы после работы скрипта - имеют права 777.
5. Скрипт "echo exec(<команда>);" дает на локальном компе весь вывод программы, на сервере - ничего не выводит (echo дает пустую строку).
6. Проверил права самих этих приложений (ffmpeg и mencoder) - права на запуск для всех.
7. Оказывается на сервере работает скрипт "echo exec('ls');" который выводит только имя php-файла, в котором этот скрипт находится. Остальные файлы не отображаются (имхо на бред похоже).
8. Пробовал в той же директории где скрипт находится, положить туда ссылку на приложение. Пробовал и мягкую и жесткую ссылку. Не работает.
9. Искал в интернете хотя бы похожую проблему. Предлагают проверить safe_mode, использовать shell_exec, проверить права, в общем ни одного намека на решение данной проблемы.
10. Пишу на форуме.

 

[dimagolov]

начни с того, что посмотри что показывает echo exec('id');

 

[sanych]

вот вывод
uid=80(www) gid=80(www) groups=80(www)

-~{}~ 25.09.09 22:26:

но если приложения имеют права на запуск для всех, имеет ли значение, какой пользователь пытается эти приложения запустить? или для www есть какие-то особые правила?

-~{}~ 25.09.09 22:57:

display_errors включил, в надежде что выдаст какую то ошибку, но и ошибки не выдает никакой

 

[dimagolov]

с учетом п.7 надо спрашивать админа сервера, в чем дело. есть подозрение, что там какой-то виртуализатор, который творит чудеса.

п.с. а если тот же ls вызвать через sudo от www:www, то что он покажет? а если запускать тот же скрипт в cli от разных юзеров?

 

[sanych]

добавлю еще пару результатов экспериментов

скрипт:

echo exec('ffmpeg 2>&1');

выводит пустую строку

скрипт:

var_dump(exec('ffmpeg 2>&1'));

выводит:
string(0) ""
подтверждая предыдущий результат

-~{}~ 26.09.09 00:21:

Автор оригинала: dimagolov
с учетом п.7 надо спрашивать админа сервера, в чем дело. есть подозрение, что там какой-то виртуализатор, который творит чудеса.

этот сервер - VDS, т.е. виртуальный выделенный, его в датацентре установили и дали нам права рута, там стандартный набор для веб-сервера, приложения ffmpeg и mencoder я устанавливал из портов самостоятельно, и работоспособность их проверял в консоли. Насчет виртуализаторов - а что имеется в виду, например?

 

[dimagolov]

ну да, VDS. он же возникает не сам по себе, а это песочница на чем-то еще, это я имел в виду под виртуализатором.

п.с. проверь что происходит в сli & cgi (от юзера www конечно), а вообще настрой nginx вместо apache, тут похоже на прикол апача.

 

[sanych]

Автор оригинала: dimagolov
п.с. а если тот же ls вызвать через sudo от www:www, то что он покажет? а если запускать тот же скрипт в cli от разных юзеров?

кстати, а как будучи залогиненым как рут выполнить команду от имени пользователя www?

-~{}~ 26.09.09 00:32:

Автор оригинала: dimagolov
ну да, VDS. он же возникает не сам по себе, а это песочница на чем-то еще, это я имел в виду под виртуализатором.
п.с. проверь что происходит в сli & cgi (от юзера www конечно), а вообще настрой nginx вместо apache, тут похоже на прикол апача.

виртуализатор разве может влиять на работу системы внутри, для сервера виртуализатор по идее неощутим
а насчет nginx - я с ним не работал ранее, и менять сервер сейчас стремно, на серваке крутятся много уже запущенных проектов

-~{}~ 26.09.09 00:33:

а может есть в настройках апача что-либо по поводу доступа к shell и к серверному софту?

 

[dimagolov]

кстати, а как будучи залогиненым как рут выполнить команду от имени пользователя www?

man sudo

а может есть в настройках апача что-либо по поводу доступа к shell и к серверному софту?

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

 

[sanych]

кстати а вот насчет CGI это мысль, надо покопать в этом направлении...

-~{}~ 26.09.09 00:38:

возможно нужно создать какой-то шлюз в cgi-bin или что-то в этом роде

 

[dimagolov]

а насчет nginx - я с ним не работал ранее, и менять сервер сейчас стремно, на серваке крутятся много уже запущенных проектов

это не больно. начинаешь с того, что настраиваешь nginx & php-fpm (много приятнее нативного php-cgi) работать демонами от пользователя www, понятно что не на 80-м порту (nginx) и смотришь что работает, а что нет. практически основной геморой в том, что нужно .htaccess конвертнуть в конфиг у ngnix, так как такого маразма как .htaccess он не поддерживает, для конвертации в нете даже скприпты находит (не не юзал)

-~{}~ 25.09.09 17:44:

п.с. php-fpm можно и с апачем сдружить, но апач все равно Г

 

[sanych]

с sudo разобрался, но неожидано проблема решилась
смешно, но расскажу как
я уже чисто по-приколу попробовал указать полный путь к приложениям, и... заработало!
оказывается, для пользователя www в переменной окружения PATH нету пути /usr/local/bin, а для рута есть ))
Самое главное что встречал рекомендации по поводу полного пути, но посчитал их глупыми ))
для подтверждения догадки запустил скрипт:

$arr = array();
exec('env',$arr);
print_r($arr);

в выводе присутствует строка: [2] => PATH=/sbin:/bin:/usr/sbin:/usr/bin
что собственно подтвердило предположение
в консоли под рутом вывод команды env совсем другой, переменных больше, и PATH более обильный ))
ну и добавление пути к программам уже в проекте показало что скрипты работают
искал как в FreeBSD добавить для конкретного пользователя путь PATH, или где расположен файл с этими путями, не нашел, поэтому просто добавил путь в скрипте

-~{}~ 26.09.09 02:06:

спасибо за поддержку ))

 

[Alexandre]

п.с. php-fpm можно и с апачем сдружить, но апач все равно Г

++1
nginx rules

-~{}~ 27.09.09 03:31:

Самое главное что встречал рекомендации по поводу полного пути, но посчитал их глупыми

надо всегда указывать полные пути, это глупая ошибка

 

[sanych]

надо всегда указывать полные пути, это глупая ошибка

ну, это уже крайность,
ведь у меня на локальном сервере не надо было, на том сервере надо было,
все зависит от того, прописан ли путь в PATH для пользователя www

 

[phprus]

sanych
В скриптах нужно всегда указывать полные пути. Прими это за аксиому.
Это позволит значительно сократить время поиска непонятно откуда возникших багов в случае, если PATH изменится по какой либо причине. Возможен даже вариант, что ты сам изменишь PATH, а потом долго будешь искать из ниоткуда возникшую ошибку. А всегда надо помнить, что баги возникают так, чтобы причинить наибольший ущерб.

 

[sanych]

окей, убедили ))
действительно, мало ли что с PATH, а прямой путь всегда будет работать

 

[Alexandre]

ну, это уже крайность,
ведь у меня на локальном сервере не надо было, на том сервере надо было,
все зависит от того, прописан ли путь в PATH для пользователя www

лучше перестраховаться ...ты же в кроне всегда указываешь полные пути, хотя можно настроить чтоб и в кроне можно было брать из /user/local/bin по умолчанию...
в одной системе настроено, в другой нет...
проще придерживаться вышепредложенному правилу.