I'm setting up Continues Integration and I'm wondering if everything should take so damn long.
My build is running for over a day in the mean time and still it's not finished.
It is a normal Laravel app with around 20 controllers, so a little time is granted, but over a day?
My config is fairly simple in my opinion:
build_settings:
ignore:
- "vendor"
setup:
composer:
action: "install"
test:
php_mess_detector:
allow_failures: true
php_code_sniffer:
standard: "PSR2"
php_cpd:
allow_failures: true
php_docblock_checker:
allowed_warnings: 10
skip_classes: true
php_loc:
directory: "src"
No errors, only the (by now) pesky status "Pending"
When I check the logs I get this error:
2016/01/28 08:01:32 [error] 6702#0: *4 FastCGI sent in stderr: "PHP message: PHP Fatal error: Class 'PHPCI\Controller' not found in /var/www/vendor/block8/b8framework/b8/Application.php on line 93" while reading response header from upstream, client: someipaddress, server: green.somedomain.com, request: "GET /assets/js/plugins/datepicker/locales/bootstrap-datepicker.en.js HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "green.somedomain.com", referrer: "http://green.somedomain.com/build/view/5"
I did composer update / install and I also added the following rule to the nginx configuration:
fastcgi_param SCRIPT_NAME index.php;
My question is, is this normal? Is my config good? Am I forgetting something?
You've not set up the build runner when you set up PHPCI. The web interface merely creates the build and displays the results, you need to run the command line tool to run the builds.
There are three ways to set this up:
(New in 1.7 beta) PHPCI Worker w/ beanstalkd.
Install beanstalkd
Use supervisord (or similar) to run /path/to/phpci/console phpci:worker
(Recommended for 1.6 and below) PHPCI Daemon: https://www.phptesting.org/wiki/Run-Builds-Using-a-Daemon
(Fallback option) Cron: https://www.phptesting.org/wiki/Run-Builds-Using-Cron
Related
This only happens on Google Chrome and Chromium with a fresh install of Laravel.
The page shows blank and in the console it says:
(failed) net::ERR_INCOMPLETE_CHUNKED_ENCODING
Instead of the default hello view that which says “You have arrived.”
My server is Debian Wheezy with ISPConfig, Apache 2.2 and PHP 5.4
Does anybody knows how can I fix this?
Had the same problem on a Ubuntu 14.04 Vagrant box running nginx. The site is a Laravel 5 that one day surprisingly started throwing those errors.
After reading this comment:
https://github.com/barryvdh/laravel-debugbar/issues/262#issuecomment-74385850
I've checked my /var/log/nginx/vagrant.com-error.log.1 and saw:
[crit] 1020#0: *774 open() "/var/lib/nginx/fastcgi/3/03/0000000033" failed (13: Permission denied) while reading upstream, client: 192.168.56.1, server: 192.168.56.102.xip.io, request: "GET /_debugbar/assets/javascript?1423122680 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "my-host", referrer: "http://url/that/fails"
Double-checked my Vagrant box nginx lib directory permissions ll /var/lib/
drwxr-xr-x 7 root root 4096 feb 9 11:28 nginx/
... where internally was using www-data user: ll /var/lib/nginx/
drwx------ 12 www-data root 4096 may 5 13:32 fastcgi/
So I ran:
chown -R www-data:www-data /var/lib/nginx
And the error in Chrome disappeared.
Just posting here to notice the solution, even all the credits should go to the linked original comment.
I had the exact same problem that you have. I found a work-around over here on this forum thread:
http://laravel.io/forum/02-08-2014-another-problem-only-with-chrome
The code used by the person who provided a the workaround: http://laravel.io/bin/eyyDj#4,7
The gist of it is to just up and tell Chrome how much data to expect for every request, so it doesn't have to chunk the data.
I'm seeing reports that upgrading to PHP 5.5 also fixes this problem, but not all of us can have that kind of control over our servers.
Edit: It looks as if blindly applying this work-around causes errors on redirects. This is the code that I'm now using:
App::after(function($request, $response) {
// Fixes a strange issue with Chrome. Should theoretically be removeable
// after upgrading PHP to 5.5 from 5.4
if ($response instanceof Illuminate\Http\Response) {
$response->header('Content-Length', strlen($response->getOriginalContent()));
}
});
Note that JSON responses are a separate type and may still have the chunking issue, so this solution may need to evolve somewhat to accommodate that.
Today I meet a strange question:
our project need to online a new module
when I execute artisan down in online environment and visit the site, I found it isn't show the maintenance page, it also show the home page
I check the CheckForMantenance Middleware has aleady add to global route middleware, the down file in storage/framework is exist
I execute php index.php it return the maintenance page, but When I visit the site from brown or curl it show the home page
I also run in test server and local, it all work well
I add a new route for test middlware, and visit the url used by curl and brown, and result is 404, the route does not found
I think it may be caused by router cache, but there is no cache file on bootstrap/cache or storage/framework, because I never open router cache!
I have no idea, so I modify the index file, add write header function at top, and redirect to a error html, the crazy thing happened it also show the home page!!!!!!
What happend? I'm sure the project path is right
Finally I reload the php-fpm and it recovery normal, the maintenance view work, redirect url work, and route normal
I don't understand still now, but I guess it may by caused by opcache?
I open the opcache ext, and use the default setting;
env:
laravel: 5.3
nginx: 1.8.1
php-fpm: 7.0.9 with opcache ext
First check your fpm logs, usually, something like this will pop up (check debug/log levels) between the notices:
[01-Mar-2017 23:59:45] NOTICE: [pool www] child 16951 started
[01-Mar-2017 23:59:48] WARNING: [pool www] child 14754
exited on signal 11 (SIGSEGV - core dumped) after 4393.427133 seconds
from start
You have to disable opcache unfortunately. I've been seeing this issue since php 5.5 all the way to 7.1 , you will also find these in the error logs:
2017/03/02 10:00:24 [error] 30498#30498: *170523 upstream timed out
(110: Connection timed out) while reading response header from upstream,
client: 81.243.144.1xx, server: fake.test.pro,
request: "POST /api/users/53e4203cfd1c46e08d5b570c2c93ff86/items HTTP/1.1",
upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock", host: "fake.test.pro",
referrer: "http://fake.test.pro/console"
In particular with Laravel, but I've also seen it on wordpress installations. It stops when I disable opcache on all versions of php-fpm
There are bugreports around on this issue but no fixes so far. I always end up doing this :
[opcache]
; Determines if Zend OPCache is enabled
opcache.enable=0
in /etc/php/7.*/fpm/php.ini files. Then my application is robust again and it costs us 150ms. it sucks.
I can't figure out why my nginx is crashing each time I try to use curl:
Code snippet to reproduce a crash:
$request = new \Buzz\Message\Request('GET', '/', 'https://google.com');
$response = new \Buzz\Message\Response();
$client = new \Buzz\Client\Curl();
$client->send($request, $response);
application log
2015/12/29 11:42:30 [error] 213#0: *416 upstream prematurely closed connection while reading response header from upstream, client: 127.0.0.1, server: dev-fr.local.xxxx.com, request: "GET /login/check-vkontakte?code=xxxxx HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "dev-ru.local.xxxx.com", referrer: "https://dev-ru.local.xxxx.com/"
/var/log/system.log
Dec 29 11:40:54 Alains-MacBook-Pro.local ReportCrash[75875]: Saved crash report for php-fpm[75864] version 0 to /Users/alain/Library/Logs/DiagnosticReports/php-fpm_2015-12-29-114054_Alains-MacBook-Pro.crash
crash report (beginning)
Process: php-fpm [75865]
Path: /usr/local/Cellar/php56/5.6.15/sbin/php-fpm
Identifier: php-fpm
Version: 0
Code Type: X86-64 (Native)
Parent Process: php-fpm [75858]
Responsible: php-fpm [75858]
User ID: 501
Date/Time: 2015-12-29 11:42:30.733 +0100
OS Version: Mac OS X 10.10.5 (14F1021)
Report Version: 11
Anonymous UUID: 1DC6CEB0-0479-4A5E-FFD2-E48BA3961196
Sleep/Wake UUID: A704AF01-8AE8-44D2-BBF3-DED65D834B0B
Time Awake Since Boot: 29000 seconds
Time Since Wake: 3000 seconds
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000110
I searched for hours and always given up, but now I'm tired and really want to fix it.
Complete crash report: http://ninsuo.com/crash-nginx-xxxx.html
My phpinfo(): http://ninsuo.com/phpinfo-xxxx.html
Better practice is to reinstall php with
brew install --with-fpm --with-homebrew-curl --with-homebrew-openssl --with-imap --with-homebrew-libxslt --without-snmp php56
and then reinstall curl with
brew install --with-openssl curl
I experienced same problem early and fixed it with running php-fpm as root.
Also I found links which confirms this solution:First link, Second link. Hope it will help you too.
I run a PHP 5.5/5.6 instance over php-fpm without any problems (unix sockets and nginx).
Today I compiled PHP 7 and also started it as a third PHP instance. While requests get served fine with the PHP 5.5/5.6 instances for the PHP 7 instance I get:
WARNING: pid 2582, fpm_request_check_timed_out(), line 277: [pool www0] child 2813, script '' (request: " ") execution timed out (120.018160 sec), terminating
in my php-fpm log file and
[error] 1889#0: *4 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx.xxx.xxx.20, server: localhost, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php70-fpm.sock:", host: "xxx.xxx.xxx.21"
in my nginx error log file.
I use fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name which also works for the PHP 5.6 instance. Although the script filename for PHP 7 seems to be empty. I'm requesting a script /info.php.
Is there any difference between using PHP 5.x and 7.0 with php-fpm?
UPDATE
At least I'm not the only one who is facing those problems as it seems. I opened a bug report here: https://bugs.php.net/bug.php?id=69850
There is also a very similar (probably identical) bug already reported over here: https://bugs.php.net/bug.php?id=69875 (thx to #crypticツ)
UPDATE 2
Try the newest alpha2. The bug is fixed there. Unix sockets work now like a charm again.
I am not sure if this can be considered as answer, but at this moment, when I am writing this answer, the bug you have raised has been deemed confirmed by the PHP Team:
[2015-06-23 12:47 UTC] remi#php.net
I confirm
PHP 5.6.10 works
PHP 7.0.0-dev (Jun 17 2015)
- network socket: OK.
- UDS: broken
Update: I just saw that you are aware of the same too!
This only happens on Google Chrome and Chromium with a fresh install of Laravel.
The page shows blank and in the console it says:
(failed) net::ERR_INCOMPLETE_CHUNKED_ENCODING
Instead of the default hello view that which says “You have arrived.”
My server is Debian Wheezy with ISPConfig, Apache 2.2 and PHP 5.4
Does anybody knows how can I fix this?
Had the same problem on a Ubuntu 14.04 Vagrant box running nginx. The site is a Laravel 5 that one day surprisingly started throwing those errors.
After reading this comment:
https://github.com/barryvdh/laravel-debugbar/issues/262#issuecomment-74385850
I've checked my /var/log/nginx/vagrant.com-error.log.1 and saw:
[crit] 1020#0: *774 open() "/var/lib/nginx/fastcgi/3/03/0000000033" failed (13: Permission denied) while reading upstream, client: 192.168.56.1, server: 192.168.56.102.xip.io, request: "GET /_debugbar/assets/javascript?1423122680 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "my-host", referrer: "http://url/that/fails"
Double-checked my Vagrant box nginx lib directory permissions ll /var/lib/
drwxr-xr-x 7 root root 4096 feb 9 11:28 nginx/
... where internally was using www-data user: ll /var/lib/nginx/
drwx------ 12 www-data root 4096 may 5 13:32 fastcgi/
So I ran:
chown -R www-data:www-data /var/lib/nginx
And the error in Chrome disappeared.
Just posting here to notice the solution, even all the credits should go to the linked original comment.
I had the exact same problem that you have. I found a work-around over here on this forum thread:
http://laravel.io/forum/02-08-2014-another-problem-only-with-chrome
The code used by the person who provided a the workaround: http://laravel.io/bin/eyyDj#4,7
The gist of it is to just up and tell Chrome how much data to expect for every request, so it doesn't have to chunk the data.
I'm seeing reports that upgrading to PHP 5.5 also fixes this problem, but not all of us can have that kind of control over our servers.
Edit: It looks as if blindly applying this work-around causes errors on redirects. This is the code that I'm now using:
App::after(function($request, $response) {
// Fixes a strange issue with Chrome. Should theoretically be removeable
// after upgrading PHP to 5.5 from 5.4
if ($response instanceof Illuminate\Http\Response) {
$response->header('Content-Length', strlen($response->getOriginalContent()));
}
});
Note that JSON responses are a separate type and may still have the chunking issue, so this solution may need to evolve somewhat to accommodate that.