2

Some pages when trying to load I receive a Bad Gateway Ngnix 502 error however upon page refresh it will resolve the page load. Not sure if this is associated however one page requires a heavy mssql query and the page will load with the result however will not continue to load CSS associated to the page.

master.blade.php file contains the bootstrap css and theme styling, extention.blade.php will extend the master (as with multiple other pages on my project) however it includes a DB query which successfully returns when dd() however fails to load the css. Other pages sometimes have this issue and multiple refresh will correct the page load.

Hope someone can help my situation. Sounds like a configuration issue? Just not sure..

UPDATE

All pages experience first a Bad Gateway 502 followed by a refresh of loss of CSS (bootstrap mainly). The Bad Gateway will come after 2 or 3 browser refresh on static pages with no association to DB queries.

My Setup:

  • Mac OS X Sierra 10.12.6
  • PHP 7.1
  • Nginx and Laravel 5.6

www.conf setup:

  • pm = dynamic
  • pm.max_children = 10
  • pm.start_servers = 10
  • pm.min_spare_servers = 10
  • pm.max_spare_servers = 10

~/.valet/Nginx/Sites.dev-env (my projects directory where Valet is parked) has the following lines (added by myself to try and resolve this issue):

`fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/Users/myusername/.valet/valet.sock;
fastcgi_index 
/Users/myusername/.composer/vendor/laravel/valet/server.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME 
/Users/myusername/.composer/vendor/laravel/valet/server.php;
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;`

php-fpm.conf setup:

  • Default with include=/usr/local/etc/php/7.1/php-fpm.d/*.conf

Laravel Storage has a 777 permission set (just to determine if its a file permission issue, this will be reverted back to 755 fyi)

Now the key to solving this issue is the error logs which provide the following:

php error log:

`[22-Feb-2018 10:29:06 Australia/Sydney] PHP Fatal error:  Uncaught 
PDOException: SQLSTATE[25000]: [FreeTDS][SQL Server]The ROLLBACK 
TRANSACTION request has no corresp$
Stack trace:
0 {main}
  thrown in [no active file] on line 0`

However, the only SQL I have related to this is a select query but I don't believe this is the main cause of the Bad Gateway.

~/.valet/log/nginx-error.log:

`2018/02/22 10:24:23 [error] 62179#0: *9 upstream prematurely closed 
connection while reading response header from upstream, client: 
127.0.0.1, server: sites.dev-env`

This I believe is the main issue. It occurs at every point of a Bad Gateway error and I am stuck trying to work out what exactly it means. This log file has a ton of these errors obviously me trying to work out what the. is going on.

How I resolve the issue temporarily is by doing a valet restart. A Brew restart of nginx or php doesn't resolve the issue, therefore, isolating this to valet.

Wick 12c
  • 133
  • 2
  • 15
  • do you see anything in ngnix logs? – FULL STACK DEV Feb 20 '18 at 05:19
  • Nothing found in the ngnix log. – Wick 12c Feb 20 '18 at 05:34
  • have you checked the removing query is it working? – FULL STACK DEV Feb 20 '18 at 05:35
  • Also found when just viewing the souce code of the page, opened up the css shows fine and the jquery script produced a bad gateway, then reopening it will be fine. It's very intermittent and not related to querying the DB after all. – Wick 12c Feb 20 '18 at 05:35
  • Found the only error is in the php log: [20-Feb-2018 16:31:53 Australia/Sydney] PHP Fatal error: Cannot redeclare valet_default_site_path() (previously declared in /Users/myusername/.composer/vendor/laravel/valet/server.php:43) in /Users/myusername/.composer/vendor/laravel/valet/server.php on line 43 – Wick 12c Feb 20 '18 at 05:38
  • may be you need to re-install valet – FULL STACK DEV Feb 20 '18 at 05:39
  • Yep I have done that and still the same error.. damn.. – Wick 12c Feb 20 '18 at 05:40
  • I have stopped valet, used php artisan serve to watch the files being loaded, artisan will stop completely after the first page (after login) – Wick 12c Feb 20 '18 at 05:45
  • php artisan optimize php artisan clear-compiled php artisan cache:clear php artisan route:clear php artisan view:clear php artisan config:clear Run tthese commands may it works – FULL STACK DEV Feb 20 '18 at 05:47
  • Also tried php artisan serve --port=8080 which worked for a single page, going to the next page stopped. – Wick 12c Feb 20 '18 at 05:50
  • when using php artisan serve, php log shows: `[20-Feb-2018 16:49:17 Australia/Sydney] PHP Fatal error: Uncaught PDOException: SQLSTATE[25000]: [FreeTDS][SQL Server]The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION. in [no active file]:0 Stack trace: #0 {main} thrown in [no active file] on line 0` – Wick 12c Feb 20 '18 at 05:52
  • I’ll give that a try tonight @adnan, mich appreciated for your time and support on this issue. – Wick 12c Feb 20 '18 at 06:30
  • all pages loaded with success then the bad gateway occurred followed by missing CSS and now cannot get the CSS back to the page (with just a page refresh). Looking at the console the bootstrap theme css is giving a "Failed to load resource: the server responded with a status of 502 ()" error. I will look into solving the bad gateway error first and hopefully it may have something to do with loading a page resource or at least narrow down the issue. – Wick 12c Feb 20 '18 at 10:45
  • make sure these files have correct permissions – FULL STACK DEV Feb 20 '18 at 11:19
  • I have checked the file permissions and are properly set. Again looking into it further I did a brew upgrade on nginx which updated nginx to still get the error however further searching on Google I then located php-fpm.log to find the following error and finding multiple child processes are failing – Wick 12c Feb 21 '18 at 00:12
  • `[21-Feb-2018 10:47:19] WARNING: [pool www] child 44641 exited on signal 11 (SIGSEGV) after 415.973817 seconds from start [21-Feb-2018 10:47:19] NOTICE: [pool www] child 45374 started` – Wick 12c Feb 21 '18 at 00:12
  • I believe it could be relating to files associated to php writing sessions from what I have read but I am not sure where the sessions are writing to considering the session handling within Laravel is within the project itself and that I have ensured the files are open for read/write. – Wick 12c Feb 21 '18 at 00:14
  • I have now narrowed down the issue. I was looking at the wrong error log. looking at the nginx error log located within the .valet directory I found: – Wick 12c Feb 21 '18 at 00:51
  • `2018/02/21 11:48:43 [error] 55477#0: *3 upstream prematurely closed connection while reading response header from upstream, client: 127.0.0.1, server: sites.dev-env, request: "GET /search HTTP/2.0", upstream: "fastcgi://unix:/Users/myusername/.valet/valet.sock:", host: "salesops.dev-env"` – Wick 12c Feb 21 '18 at 00:51
  • you cannot have a dash in the host name, can you? – Yevgeniy Afanasyev Feb 23 '18 at 01:52

2 Answers2

0

I know only one reason why the page may not load on the first place, but load on the other. It is about Redirect::back()->withInput(Input::all());

On the first load there might be some inputs, on the refresh - no input would be left.

Yevgeniy Afanasyev
  • 37,872
  • 26
  • 173
  • 191
  • No this is incorrect. This error occurs on every page from static to DB driven query pages. This is not isolated to a specific page and pages with no input at all. – Wick 12c Feb 22 '18 at 23:17
  • Well, anyway it is something to do with session, most likely login-engine, I believe. Can you Log::debug(... the contains of the sessions when there is a problem and when the problems is gone to see the difference? – Yevgeniy Afanasyev Feb 23 '18 at 01:50
  • Thank you Yevgeniy as that helps. I have Spatie User permissions package installed and just added now barryvdh/laravel-debugbar to view the routes, queries and session. It looks like Spatie's user permission is making 3 queries to gather user, roles and permissions when the query should be consolidated into one but I didn't find anything outside of this. Do you have any recommendation on debugging sessions within Laravel? – Wick 12c Feb 23 '18 at 03:26
0

Just commenting here as I've come across another scenario that can cause this. Note that Yevgeniy's answer is also correct in causing a 502 if there is no referer header information.

Under load I was able to identify that that database was being hit particularly hard by some poorly performing queries. These queries appeared to be holding our database up and in doing so was causing the web server to go up and down several times a minute. It appeared as though PHP-FPM was constantly opening/closing database connections - maybe as a result of the open connections stalling due to the load.

Anyway - as a general answer to this, database struggles might result in your web tier locking up and getting returning a 502 error. Laravel doesn't give you must helpful information in this instance, but checking your database is something you may want to do if you start receiving intermittent errors like this.

Dwight
  • 12,120
  • 6
  • 51
  • 64