Is mod_exedir compatible with PHP 7.1

Question

Is mod_exedir compatible with PHP 7.1

digirave opened this issue 7 years ago · 12 comments

This is my current setup:
rpm -qa|grep php71
php71-php-pecl-apcu-5.1.8-1.el7.remi.x86_64
php71-php-fpm-7.1.9-1.el7.remi.x86_64
php71-php-imap-7.1.9-1.el7.remi.x86_64
php71-php-pecl-redis-3.1.2-1.el7.remi.x86_64
php71-php-xml-7.1.9-1.el7.remi.x86_64
php71-php-cli-7.1.9-1.el7.remi.x86_64
php71-php-mysqlnd-7.1.9-1.el7.remi.x86_64
php71-php-process-7.1.9-1.el7.remi.x86_64
php71-runtime-1.0-1.el7.remi.x86_64
php71-php-pecl-igbinary-2.0.4-1.el7.remi.x86_64
php71-php-pecl-memcache-3.0.9-0.7.20161124gitdf7735e.el7.remi.x86_64
php71-php-common-7.1.9-1.el7.remi.x86_64
php71-php-soap-7.1.9-1.el7.remi.x86_64
php71-php-pecl-geoip-1.1.1-3.el7.remi.x86_64
php71-php-pecl-memcached-3.0.3-1.el7.remi.x86_64
php71-php-json-7.1.9-1.el7.remi.x86_64
php71-php-7.1.9-1.el7.remi.x86_64
php71-php-mcrypt-7.1.9-1.el7.remi.x86_64
php71-php-tidy-7.1.9-1.el7.remi.x86_64
php71-php-pecl-sphinx-1.4.0-0.2.20170203git201eb00.el7.remi.x86_64
php71-php-pdo-7.1.9-1.el7.remi.x86_64
php71-php-devel-7.1.9-1.el7.remi.x86_64
php71-php-xmlrpc-7.1.9-1.el7.remi.x86_64
php71-php-bcmath-7.1.9-1.el7.remi.x86_64
php71-php-pecl-apcu-bc-1.0.3-6.el7.remi.x86_64
php71-php-pecl-msgpack-2.0.2-1.el7.remi.x86_64
php71-php-opcache-7.1.9-1.el7.remi.x86_64
php71-php-pear-1.10.5-2.el7.remi.noarch
php71-php-pecl-zip-1.15.1-1.el7.remi.x86_64
php71-php-pecl-imagick-3.4.3-5.el7.remi.x86_64
php71-php-gd-7.1.9-1.el7.remi.x86_64
php71-php-snmp-7.1.9-1.el7.remi.x86_64
php71-php-mbstring-7.1.9-1.el7.remi.x86_64

This is my current setup for php-exec:
cd /root/php
rm /root/php/mod_execdir -rf
git clone https://github.com/OOPS-ORG-PHP/mod_execdir/
cd /root/php/mod_execdir
/opt/remi/php71/root/usr/bin/phpize
./configure --with-execdir= --with-php-config=/opt/remi/php71/root/usr/bin/php-config
make test PHP_EXECUTABLE=/usr/bin/php71
make install

Test fails:
PHP : /usr/bin/php71
PHP_SAPI : cli
PHP_VERSION : 7.1.9
ZEND_VERSION: 3.1.0
PHP_OS : Linux - Linux f100.test.com 3.10.0-693.1.1.el7.x86_64 #1 SMP Wed Aug 23 13:08:16 UTC 2017 x86_64
INI actual : /root/setupSync/php/mod_execdir/tmp-php.ini
More .INIs :
CWD : /root/setupSync/php/mod_execdir
Extra dirs :
VALGRIND : Not used
TIME START 2017-09-18 15:22:30
PASS Check for jailed_shellcmd function [tests/000-jailed_shellcmd.phpt]
PASS Check for exec_re function that has command not found [tests/001-exec-failed.phpt]
PASS Check for exec_re function that return success [tests/001-exec-normal.phpt]
PASS Check for system_re function that has command not found [tests/002-system-failed.phpt]
PASS Check for system_re function that return success [tests/002-system-normal.phpt]
PASS Check for passthru_re function that has command not found [tests/003-passthru-failed.phpt]
PASS Check for passthru_re function that return success [tests/003-passthru-normal.phpt]
PASS Check for shell_exec_re function that return success [tests/004-shell_exec-failed.phpt]
PASS Check for shell_exec_re function that return success [tests/004-shell_exec-normal.phpt]
PASS Check for popen_re function that return success [tests/005-popen-failed.phpt]
PASS Check for popen_re function that return success [tests/005-popen-normal.phpt]
PASS Check for proc_open_re function that has command not found [tests/006-proc_open-failed.phpt]
PASS Check for proc_open_re function that return success [tests/006-proc_open-normal.phpt]
PASS Check for pcntl_exec_re function that has command not found [tests/007-pcntl_exec-failed.phpt]
PASS Check for pcntl_exec_re function that return success [tests/007-pcntl_exec-normal.phpt]
PASS Check for shell redirection [tests/008-redirection.phpt]
PASS Check for NULL byte detected error [tests/009-twice_same_command.phpt]
TIME END 2017-09-18 15:22:31

TEST RESULT SUMMARY
Exts skipped : 0
Exts tested : 15

Number of tests : 17 17
Tests skipped : 0 ( 0.0%) --------
Tests warned : 0 ( 0.0%) ( 0.0%)
Tests failed : 0 ( 0.0%) ( 0.0%)
Expected fail : 0 ( 0.0%) ( 0.0%)
Tests passed : 17 (100.0%) (100.0%)
Time taken : 1 seconds

This report can be automatically sent to the PHP QA team at
http://qa.php.net/reports and http://news.php.net/php.qa.reports
This gives us a better understanding of PHP's behavior.
If you don't want to send the report immediately you can choose
option "s" to save it. You can then email it to qa-reports@lists.php.net later.
Do you want to send this report now? [Yns]:

Real world tests:
exec seems to limit exec to the selected directly properly, however
I am seeing random segfault when using execdir extension with exec() and ffmpeg
Also, exec_orig works on PHP 5.6 but doesn't seem to work on php 7.1

Everything works okay when disabling execdir, and all php coredumps go away.

Answer 1 · 2017-09-18T06:35:48.000Z

example of segfault
exec("/etc/phpexec/ffmpeg -y -i " . escapeshellarg($filename) . ' -c:v libvpx -crf 12 -b:v 500K -auto-alt-ref 0 ' . escapeshellarg($filename2));

-> random segfault (sometimes works) when using execdir extension:

Sep 18 14:27:32 f100 kernel: php-fpm[1405]: segfault at 600000001 ip 0000559d55a582f0 sp 00007ffda56c06d0 error 4
Sep 18 14:27:32 f100 abrt-hook-ccpp: Process 1405 (php-fpm) of user 48 killed by SIGSEGV - dumping core
Sep 18 14:27:33 f100 abrt-hook-ccpp: /var/spool/abrt is 1714774365 bytes (more than 1279MiB), deleting 'ccpp-2017-09-18-14:26:24-1404'

Answer 2 · 2017-09-18T17:51:48.000Z

You asked me two questions.

First, I ask for some information to resolve the segfault problem.

Can you provide me with a coredump file or a backtrace of the point where segfault occurs?

I want to know the exact command line command where the variable value has been processed. I would like to know the output of the following code.

#exec("/etc/phpexec/ffmpeg -y -i " . escapeshellarg(XE_PATH.$filename) . ' -c:v libvpx -crf 12 -b:v 500K -auto-alt-ref 0 ' . escapeshellarg(XE_PATH.$filename2));
echo "/etc/phpexec/ffmpeg -y -i " . escapeshellarg(XE_PATH.$filename) . ' -c:v libvpx -crf 12 -b:v 500K -auto-alt-ref 0 ' . escapeshellarg(XE_PATH.$filename2) . "\n";

Does segfault occur in php 5.6 as well?

Secondly, whether or not the __orig function works in PHP 7.1.

As a result of my testing, the _orig function seems to work fine on PHP 7.1 environment.

To use the _orig function, you must specify the --with-execdir-compat option at configure time with Master branch code (1.0.2-dev).

This test environment is not remi's PHP 7.1 environment. I will test it again in remi's PHP 7.1 environment and let me know it again. Your results do not seem to be a problem with PHP 7.1. Perhaps this is happening in remi's PHP 7.1 environment.

test code :

<?php
echo "#### test exec('ls -al', \$m) ....\n";
echo exec('ls -al', $m) . "\n";
echo "#### test exec_orig('ls -al', \$m) ....\n";
echo exec_orig('ls -al', $m) . "\n";
?>

result :

[root@an3 mod_execdir]$ php71 -d "exec_dir=/var/bin/asdf" a.php
#### test exec('ls -al', $m) ....
sh: /var/bin/asdf/ls: No such file or directory

#### test exec_orig('ls -al', $m) ....
drwxr-xr-x  2 root root   4096 Sep  1 01:14 tests

For test, php version is :

[root@an3 mod_execdir]$ php71 --version
PHP 7.1.9AnNyung (cli) (built: Sep  1 2017 23:57:32) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies

Answer 3 · 2017-09-18T18:39:52.000Z

This is Remi's PHP environment:

Environments :

[root@vm-an3 mod_execdir]$ cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
[root@vm-an3 mod_execdir]$
[root@vm-an3 mod_execdir]$ php71 -v
PHP 7.1.9 (cli) (built: Aug 30 2017 19:11:42) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
[root@vm-an3 mod_execdir]$
[root@vm-an3 mod_execdir]$ rpm -qa | grep php71
php71-runtime-1.0-1.el7.remi.x86_64
php71-php-devel-7.1.9-1.el7.remi.x86_64
php71-php-json-7.1.9-1.el7.remi.x86_64
php71-php-cli-7.1.9-1.el7.remi.x86_64
php71-php-common-7.1.9-1.el7.remi.x86_64
[root@vm-an3 mod_execdir]$
[root@vm-an3 mod_execdir]$
[root@vm-an3 mod_execdir]$
[root@vm-an3 mod_execdir]$ cat /etc/opt/remi/php71/php.d/20-execdir.ini
extension=execdir.so
[root@vm-an3 mod_execdir]$
[root@vm-an3 mod_execdir]$ ls -al /var/bin/
합계 0
drwxr-xr-x   2 root root  20  9월 19 03:25 .
drwxr-xr-x. 20 root root 278  9월 19 03:25 ..
lrwxrwxrwx   1 root root  15  9월 19 03:25 ffmpeg -> /usr/bin/ffmpeg
[root@vm-an3 mod_execdir]$

test code :

<?php
for ( $i=0; $i<10000; $i++ ) {
    echo $i."\n";
    if ( file_exists ('mpthreetest.ogg') )
        unlink ('mpthreetest.ogg');
    exec("ffmpeg -i mpthreetest.mp3 -c:a libvorbis -q:a 4 mpthreetest.ogg >& /dev/null");
}
?>

test result :
No segfault

[root@vm-an3 mod_execdir]$ php71 -d 'exec_dir=/var/bin' z.php

Perhaps there is a conflict in the FPM environment or there is another reason. I can not find a problem in an environment that simply executes execdir code.

The coredump file with the symbol or the backtrace when setfault occurs will help me to solve the problem more.

P.S.
In remi's PHP environment, the _orig functions worked well too.

Answer 4 · 2017-09-30T08:56:19.000Z

The problems occurs only sometimes in tests, but in production very often.
When converting large .gif files to .webm it seems to occur more often (it is not 100% even with same command).
When converting to .mp4, the problem doesn't seem to occur (or is very rare).

I fixed this immediately on all production servers by just disabling mod_execdir.
All problems went away after disabling mod_execdir.

Can you provide me with a coredump file or a backtrace of the point where segfault occurs?

I actually have not done this before.
Do you have a recommended method on providing such information?

I want to know the exact command line command where the variable value has been processed. I would like to know the output of the following code.

I currently do not have the information.

Does segfault occur in php 5.6 as well?

I did not test in php 5.6.

Secondly, whether or not the __orig function works in PHP 7.1.

That is probably my mistake.
I did not know that --with-execdir-compat option was added.

Answer 5 · 2017-10-01T15:12:38.000Z

show me the execdir configuraiton of phpinfo(). For examples:

And, please also tell me the result of the next command:

[root@host ~]$ php71 -m

P.S.
Looking at your hostname, I think you are Korean.
If you are Korean, you can write in Korean. I am also more comfortable with Korean.

Answer 6 · 2017-10-01T15:26:29.000Z

Looking at your hostname, I think you are Korean.

보안상 hostname은 지웠습니다.

나머지 부분은 오류로 인해 yum update 및 git 에서 exec_dir 다시 다운 받고 난 뒤에,
오류 없어지는지 시도하고 오류가 없어지지 않아서 exec_dir이 제거된 상태입니다.
현재 제거된 상태라서, 추후 여유가 될 때 다시 테스트 가능할때 말씀 드리겠습니다.
이후에 PHP 소스 코드도 다량 수정하고 일부 문제를 일으킨 소스 코드를 버린 상태로, 제가 다시 켜도 당장 발생하지는 않을 것 같긴 합니다.
해당 부분은 참고로 별도의 서버 장비 5대, 별도의 vmware 2대에서 발생하긴 했습니다.
1대는 타인이 운영하는 테스트 환경이었습니다.

현재의 환경은 (아마도 오류 마지막 나온 환경이란 같을 것이긴 합니다):
php71 -m
[PHP Modules]
apc
apcu
bcmath
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
geoip
gettext
hash
iconv
igbinary
imagick
imap
json
libxml
mbstring
mcrypt
memcache
memcached
msgpack
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
posix
readline
redis
Reflection
session
shmop
SimpleXML
snmp
soap
sockets
sphinx
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tidy
tokenizer
wddx
xml
xmlreader
xmlrpc
xmlwriter
xsl
Zend OPcache
zip
zlib

[Zend Modules]
Zend OPcache

Answer 7 · 2017-10-01T16:30:07.000Z

php.ini 의 exec_dir 옵션값은 어떻게 지정했나요? 컴파일시에 exec_dir 의 기본값을 NULL 로 지정을 하셨던데..

설치된 환경과 동일한 환경을 만들어 테스트를 하려고 하니, exec_dir 의 옵션 값을 알려 주십시오.

coredump나 backtrace 정보가 있으면 유추가 가능할텐데.. 이걸 하는 방법을 알려 달라고 하시는 것에 대한 답변이 쉽지 않아 제가 직접 환경을 구성해서 segfault 가 발생하기를 바라는 수 밖에 없겠네요.

Answer 8 · 2017-10-01T16:49:29.000Z

스크립트로 자동화해서 아래는 정확합니다:

cd /root/setupFiles/php
rm /root/setupFiles/php/mod_execdir -rf
git clone https://github.com/OOPS-ORG-PHP/mod_execdir/
cd /root/setupFiles/php/mod_execdir
/opt/remi/php71/root/usr/bin/phpize
./configure --with-execdir= --with-php-config=/opt/remi/php71/root/usr/bin/php-config
make test PHP_EXECUTABLE=/usr/bin/php71
make install

cp /root/setupFiles/setup/etc/opt/remi/php71/php.d/execdir.ini /etc/opt/remi/php71/php.d/execdir.ini

execdir.ini 의 내용은 최근에 제거해서 확실하지 않은데

extension = execdir.so
exec_dir =
이거나
;exec_dir =

이었는데,
-> exec_dir = 이부분을 제가 지금 ; 해놔서, 원래 그랬는지 기억이 안 납니다. 물론 exec_dir는 php-fpm 에서 setting되어 있습니다.

주요 php-fpm setting은

php_flag[display_errors] = off
php_admin_value[allow_url_fopen] = off
php_admin_value[disable_functions] = shell_exec,popen,show_source,exec_orig,system_orig,passthru_orig,shell_exec_orig,popen_orig,proc_open_orig,proc_close_orig,proc_terminate_orig,proc_get_status_orig

php_admin_value[exec_dir] = /etc/phpexec

php_admin_flag[log_errors] = on

request_terminate_timeout=60s

기타 주요 세팅:
apcu 는 활성화 상태입니다.

오류 일으키는데 사용된 ffmpeg는 공식 홈페이지에서 static compiled binary입니다:
ffmpeg-release-64bit-static.tar.xz

 ./ffmpeg  -version
ffmpeg version 3.3.3-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.4.0 (Debian 6.4.0-2) 20170724
configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-6 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gray --enable-libass --enable-libfreetype --enable-libfribidi --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libzimg
libavutil      55. 58.100 / 55. 58.100
libavcodec     57. 89.100 / 57. 89.100
libavformat    57. 71.100 / 57. 71.100
libavdevice    57.  6.100 / 57.  6.100
libavfilter     6. 82.100 /  6. 82.100
libswscale      4.  6.100 /  4.  6.100
libswresample   2.  7.100 /  2.  7.100
libpostproc    54.  5.100 / 54.  5.100

Answer 9 · 2017-10-01T18:47:55.000Z

일단 최대한 비슷한 환경을 꾸며서 테스트를 해 보았으나, 문제 재현이 되지를 않네요. 일단 OS 버전과 web server 및 web server 설정을 몰라 이 부분은 임의로 환경을 구성 했습니다.

segfault가 발생하는데, mod_execdir을 제거하면 segfault가 발생하지 않는다고 하시는 것으로 보아 문제가 있는 것 같은데, 일단은 어떤 특수한 환경에서 발생하는 듯 싶습니다. 일단 webm 으로 변환시에 자주 발생하고, mp4 변환시에는 자주 발생하지 않는 다는 경우는 이 문제에 해당되지 않을 것 같고요. 아마도 process가 rotate 될때 php module shutdown 시에 발생하는 것이 아닐까 의심이 되기는 합니다만, mod_execdir 자체의 코드에서는 특별히 문제될 부분이 보이지는 않네요.

이래서 coredump의 backtrace 정보가 있으면 유추가 가능한데, coredump를 남기는 법을 모르신다고 하니 좀 애매합니다. 일단은, "CentOS 7 coredump" 이런 식으로 검색을 하면 core dump를 남기는 방법에 대해서 찾을 수 있기는 합니다.

backtrace 정보는, coredump 파일이 생성이 되었다면 gdb를 이용하여 다음 명령으로 가능 합니다.

[root@vm-an3 ~]$ gdb /opt/remi/php71/root/usr/sbin/php-fpm core.123456
.....
(gdb) backtrace

그리고, ffmpeg을 exec로 구동 시키는 것 보다는 ffmpeg-php module을 이용하시는 것을 권고 드리고 싶네요.

다음은, 제가 테스트한 환경 입니다.

OS : CentOS 7.4
Web server : Apache 2.4.6 (CentOS default httpd package)

Timeout 60s
KeepAlive on
MPM: event

mod_execdir :

PHP : remi's php71 (위에 전달해 준 package 모두 설치 구성)

[root@vm-an3 html]$ rpm -qa | grep php71
php71-php-json-7.1.10-1.el7.remi.x86_64
php71-php-pecl-igbinary-2.0.4-1.el7.remi.x86_64
php71-php-pecl-apcu-5.1.8-1.el7.remi.x86_64
php71-php-mysqlnd-7.1.10-1.el7.remi.x86_64
php71-php-pecl-imagick-3.4.3-5.el7.remi.x86_64
php71-php-soap-7.1.10-1.el7.remi.x86_64
php71-php-mbstring-7.1.10-1.el7.remi.x86_64
php71-runtime-1.0-1.el7.remi.x86_64
php71-php-common-7.1.10-1.el7.remi.x86_64
php71-php-xml-7.1.10-1.el7.remi.x86_64
php71-php-pdo-7.1.10-1.el7.remi.x86_64
php71-php-pecl-msgpack-2.0.2-1.el7.remi.x86_64
php71-php-pecl-apcu-bc-1.0.3-6.el7.remi.x86_64
php71-php-pear-1.10.5-2.el7.remi.noarch
php71-php-pecl-redis-3.1.2-1.el7.remi.x86_64
php71-php-devel-7.1.10-1.el7.remi.x86_64
php71-php-bcmath-7.1.10-1.el7.remi.x86_64
php71-php-mcrypt-7.1.10-1.el7.remi.x86_64
php71-php-pecl-memcache-3.0.9-0.7.20161124gitdf7735e.el7.remi.x86_64
php71-php-fpm-7.1.10-1.el7.remi.x86_64
php71-php-imap-7.1.10-1.el7.remi.x86_64
php71-php-pecl-geoip-1.1.1-3.el7.remi.x86_64
php71-php-snmp-7.1.10-1.el7.remi.x86_64
php71-php-cli-7.1.10-1.el7.remi.x86_64
php71-php-process-7.1.10-1.el7.remi.x86_64
php71-php-pecl-memcached-3.0.3-1.el7.remi.x86_64
php71-php-xmlrpc-7.1.10-1.el7.remi.x86_64
php71-php-tidy-7.1.10-1.el7.remi.x86_64
php71-php-pecl-zip-1.15.1-1.el7.remi.x86_64
php71-php-gd-7.1.10-1.el7.remi.x86_64
php71-php-opcache-7.1.10-1.el7.remi.x86_64
[root@vm-an3 html]$ cat /etc/opt/remi/php71/php-fpm.d/www.conf
...
listen = /var/run/php-fpm-default.sock
pm.max_children = 500
pm.start_servers = 100
pm.min_spare_servers = 100
pm.max_spare_servers = 200
pm.process_idle_timeout = 10s;
catch_workers_output = yes
request_terminate_timeout = 60s
...
php_admin_value[allow_url_fopen] = off
php_admin_value[disable_functions] = shell_exec,popen,show_source,exec_orig,system_orig,passthru_orig,shell_exec_orig,popen_orig,proc_open_orig,proc_close_orig,proc_terminate_orig,proc_get_status_orig
php_admin_value[exec_dir] = /etc/phpexec

ffmpeg : 공식 homepage의 3.3.3 static version (현재는 3.3.4가 relese 되어 있어서 동일하게 3.3.3 으로 받음)

[root@vm-an3 z]$ wget https://johnvansickle.com/ffmpeg/releases/ffmpeg-3.3.3-64bit-static.tar.xz
--2017-10-02 02:46:55--  https://johnvansickle.com/ffmpeg/releases/ffmpeg-3.3.3-64bit-static.tar.xz
Resolving johnvansickle.com (johnvansickle.com)... 162.222.226.121
Connecting to johnvansickle.com (johnvansickle.com)|162.222.226.121|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 18093428 (17M) [application/x-xz]
Saving to: ‘ffmpeg-3.3.3-64bit-static.tar.xz’

100%[=====================================================================================================================================>] 18,093,428  3.72MB/s   in 6.8s

2017-10-02 02:47:03 (2.53 MB/s) - ‘ffmpeg-3.3.3-64bit-static.tar.xz’ saved [18093428/18093428]
[root@vm-an3 z]$ /etc/phpexec/ffmpeg -version
ffmpeg version 3.3.3-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.4.0 (Debian 6.4.0-2) 20170724
configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-6 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gray --enable-libass --enable-libfreetype --enable-libfribidi --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libzimg
libavutil      55. 58.100 / 55. 58.100
libavcodec     57. 89.100 / 57. 89.100
libavformat    57. 71.100 / 57. 71.100
libavdevice    57.  6.100 / 57.  6.100
libavfilter     6. 82.100 /  6. 82.100
libswscale      4.  6.100 /  4.  6.100
libswresample   2.  7.100 /  2.  7.100
libpostproc    54.  5.100 / 54.  5.100

PHP test code :

disk 부하가 너무 심해서 /dev/null 로 저장 시켰습니다.
5M 사이즈의 animate gif를 webm 으로 변환 시켰습니다.
https://giphy.com/gifs/ashley-sky-fashion-model-CZedlPSpZ6hKo

<?php
exec ("/etc/phpexec/ffmpeg -v -8 -y -i 한글+1/a.gif -c:v libvpx -crf 12 -b:v 500K -auto-alt-ref 0 /dev/null");
?>

Test :

[root@old shm]$ ab -n 100000 -c 50 -s 1000 http://vm-an3.xen.kldp.org/
This is ApacheBench, Version 2.3 <$Revision: 1796539 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking vm-an3.xen.kldp.org (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software:        Apache/2.4.6
Server Hostname:        vm-an3.xen.kldp.org
Server Port:            80

Document Path:          /
Document Length:        0 bytes

Concurrency Level:      50
Time taken for tests:   2417.617 seconds
Complete requests:      100000
Failed requests:        48768
   (Connect: 0, Receive: 0, Length: 48768, Exceptions: 0)
Non-2xx responses:      2
Total transferred:      5203564402 bytes
HTML transferred:       5186364204 bytes
Requests per second:    41.36 [#/sec] (mean)
Time per request:       1208.809 [ms] (mean)
Time per request:       24.176 [ms] (mean, across all concurrent requests)
Transfer rate:          2101.91 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   1.3      1      62
Processing:     8 1207 1158.9   1760   55547
Waiting:        4 1198 1164.5   1760   55485
Total:          9 1209 1158.9   1761   55548

Percentage of the requests served within a certain time (ms)
  50%   1761
  66%   1951
  75%   1999
  80%   2025
  90%   2085
  95%   2133
  98%   2189
  99%   2231
 100%  55548 (longest request)

Answer 10 · 2017-10-01T18:49:44.000Z

일반적인 환경에서 발생하는 문제는 아닌 것 같고, 이 문제를 해결하기 위해서는 재현이 가능한 환경 정보 또는 coredump 파일이나, 아니면 최소한 coredump 파일의 backtrace 정보가 있어야 해결이 가능 할 듯 싶습니다.

Answer 11 · 2017-10-10T15:08:42.000Z

Helo!

Very interested (a lot) in this problems... I can at least say THANKS SO MUCH!!! for bringing this to latests phps.

(But i cannot read korean! hehehe)

Answer 12 · 2021-03-28T18:48:42.000Z

It is not reproduced, and the ticket is closed.