When CLI was not built but only CGI binary, then a sequence of
$ ./buildconf
$ ./configure --prefix=/usr/local/phpcgi --disable-cli
$ make -j8
$ sudo rm -rf /usr/local/phpcgi
$ sudo make install
results in the following error:
/bin/bash /srv/smb/php-src.test/libtool --silent --preserve-dup-deps --mode=install cp ext/opcache/opcache.la /srv/smb/php-src.test/modules
Installing shared extensions: /usr/local/phpcgi/lib/php/extensions/no-debug-non-zts-20121212/
Installing PHP CGI binary: /usr/local/phpcgi/bin/
cp: cannot create regular file `/usr/local/phpcgi/bin/#INST@28245#': No such file or directory
make: *** [install-cgi] Fehler 1
The solution is to create the binary directory before copying the
CGI binary as e.g. CLI does.
Signed-off-by: Oliver Metz <oliver.metz@gmx.de>
[extensive commit message]
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
This previously used a buggy implementation of binary search that would loop
infinitely for unknown codes when searching in reason arrays of particular
sizes (such as the one we have at the moment). Since C provides bsearch(),
we'll just use that instead, since libc authors hopefully get this right.
There was also an additional bug that was masked by the first one: the design
was that an unknown code would result in get_status_string() returning NULL,
which would then result in a segfault in append_http_status_line(), since it
assumed that it would always receive a valid string pointer that could be
handed off to smart_str_appends_ex(). We'll now return a placeholder in that
case.
Fixes bug #65066 (Cli server not responsive when responding with 422 http
status code).
systemd_interval option to configure this. The service can now use
Type=notify in the systemd unit file.
Systemd status line will looks like:
Status: "Processes active: 0, idle: 5, Requests: 90, slow: 0, Traffic: 10req/sec"
Watchdog mode is also supported. In this case watchdog interval,
configured in the unit file, override the systemd_interval option.
When not used (default), no change from previous version.
To not alter current behaviour, we simply log the problem,
so, if it occurs, the message will give explanation.
This are only warning as they don't block the server,
but such fail can explain strange (not expected) behaviour later.
* PHP-5.3:
From code coverity scan - fix some memory leak - fix some resources leak (fd) - create fpm_worker_pool_free (shared use) - possible null dref (wp->user and wp->home can be null)
- fix some memory leak
- fix some resources leak (fd)
- create fpm_worker_pool_free (shared use)
- possible null dref (wp->user and wp->home can be null)
the SCRIPT_FILENAME may contains the QUERY_STRING.
Ex : RewriteRule ^(.*)\.php$ fcgi://127.0.0.1:9000/$1.php [P]
From apache debug (build with -DFCGI_DUMP_ENV_VARS)
AH01062: sending env var 'SCRIPT_FILENAME' value 'proxy:fcgi://127.0.0.1:9000/var/www/html/info.php?foo'
AH01071: Got error 'Primary script unknown\n'
Added descriptions for the new HTTP codes:
- 428 Precondition Required
- 429 Too Many Requests
- 431 Request Header Fields Too Large
- 511 Network Authentication Required
fdset management using bit operator is broken on non-x86 arch
and cause built-in server the enter an infinite loop of "select"
and never handle any request.
