[PHP] error_log regels willekeurig "afgekapt"

[Kevin-de-Groot]

Hi,

Ik help iemand met het verhelpen van de errors op de website. De foutmeldingen werden nooit getoond en naar de error_log werd nooit omgekeken. Aan mij nu de taak om de errors die in de log staan te verhelpen.

Ik heb verder weinig tot geen verstand van servers en de configuratie ervan. Ik weet dat er een tijd geleden (vóór mij) voor gekozen is om over te stappen van Apache naar Nginx.

Als ik verbinding maak met de webserver (middels Putty), dan krijg ik het volgende te zien:

Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-32-generic x86_64)

Als ik vervolgens commando uname -a uitvoer, dan krijg ik dit:

Linux <servername> 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Commando lsb_release -a geeft het volgende:

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty

Commando cat /etc/lsb-release geeft het volgende:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"

Als ik de PHP constante PHP_VERSION weergeef, dan krijg ik: 5.6.23-1+deprecated+dontuse+deb.sury.org~trusty+1. Dat lijkt me sowieso al niet goed, maar goed.

Enkele regels in de error_log:

PHP message: PHP Warning: Cannot use a scala

PHP message: PHP Notice: Trying to

PHP message: PHP Notice:

PHP message: PHP Notice: Undefined variable: pn_info_array in /var/www/kev

PHP message: PHP Notice: Undefined variable: return_array in /var

PHP m

2017/01/23 12:05:06 [error] 6392#6392: *460875 FastCGI sent in stderr: ".php on line 1698

2017/01/23 10:45:02 [error] 6390#6390: *453243 FastCGI sent in stderr: "ine 89

Ik schat dat zo'n één derde van de log gevuld is met dergelijke regels. Ik kan hier weinig mee. Iemand enig idee hoe dit kan komen? Sorry als de gegeven informatie wat gebrekkig is.

Wellicht had dit in een ander forum gemoeten, maar ik weet het niet zeker. Als dit in een ander forum had gemoeten, dan mijn excuses.

[ Voor 9% gewijzigd door Kevin-de-Groot op 23-01-2017 13:01 ]

[llevering]

Staat de schijf van de server niet (bijna) vol? Incomplete error logs zijn daarvoor bijna altijd de eerste red flag.

[Kevin-de-Groot]

llevering schreef op maandag 23 januari 2017 @ 15:13:
Staat de schijf van de server niet (bijna) vol? Incomplete error logs zijn daarvoor bijna altijd de eerste red flag.

Bedankt voor je reactie.
De schijf is nog niet vol, nog lang niet zelfs. Er is 13% in gebruik. Na die incomplete regels komen er ook gewoon normale regels. Ik vermoed dat meerdere regels met dezelfde fout te maken hebben. Hier nog een screenshot van een deel van de error log. Dit is uitgelezen via een PHP-script, maar ik heb het ook bekeken vanaf de commandline met tail en rechtstreeks geopend vanaf de server in Sublime Text en Notepad++.

Edit: ik heb de beschikbare ruimte gecontroleerd middels commando df -T -h.

Edit 2: ik vermoed dat het iets met FastCGI óf Nginx is. Ik heb dit nog niet eerder bij Apache gezien. Ik heb overigens ook nog nooit "FastCGI-errors" (zoals 2017/01/23 11:50:45 [error] 6396#6396: *459468 FastCGI sent in stderr: ".php on line 1698) gezien.

Edit 3: ik zie nu net ook dit (klik) topic. Helaas is daar geen antwoord op ontvangen. In dat geval gaat het om Apache, niet om Nginx.

[ Voor 26% gewijzigd door Kevin-de-Groot op 23-01-2017 15:35 ]

[martijncalker]

Voor zover ik weet vind Nginx het niet leuk als php naar stdout of stderr logt. Kan je php zo configgen dat 'ie naar een file schrijft?

[Kevin-de-Groot]

martijncalker schreef op maandag 23 januari 2017 @ 16:33:
Voor zover ik weet vind Nginx het niet leuk als php naar stdout of stderr logt. Kan je php zo configgen dat 'ie naar een file schrijft?

Ik weet nog niet hoe, maar dat ga ik uitzoeken. Maar dat zou alleen die "FastCGI-errors" verhelpen, of niet? Ik ben echt niet thuis in dit soort dingen. Ik installeer XAMP en als het werkt, werkt het. En het werkt, zeg maar Ook error logging werkt out-of-the-box

Edit: dit zijn wat regels uit de php-fpm.conf:

; This directive controls whether or not and where PHP will output errors,
; notices and warnings too. Error output is very useful during development, but
; it could be very dangerous in production environments. Depending on the code
; which is triggering the error, sensitive information could potentially leak
; out of your application such as database usernames and passwords or worse.
; For production environments, we recommend logging errors rather than
; sending them to STDOUT.
; Possible Values:
; Off = Do not display any errors
; stderr = Display errors to STDERR (affects only CGI/CLI binaries!)
; On or stdout = Display errors to STDOUT
; Default Value: On
; Development Value: On
; Production Value: Off
; http://php.net/display-errors
display_errors = Off


; Besides displaying errors, PHP can also log errors to locations such as a
; server-specific log, STDERR, or a location specified by the error_log
; directive found below. While errors should not be displayed on productions
; servers they should still be monitored and logging is a great way to do that.
; Default Value: Off
; Development Value: On
; Production Value: On
; http://php.net/log-errors
log_errors = On


; Log errors to specified file. PHP's default behavior is to leave this value
; empty.
; http://php.net/error-log
; Example:
;error_log = php_errors.log
; Log errors to syslog (Event Log on Windows).
;error_log = syslog

[ Voor 59% gewijzigd door Kevin-de-Groot op 23-01-2017 16:50 ]

[Kevin-de-Groot]

Ik heb de access-log ingeschakeld en deze bekeken. Deze wordt niet halverwege afgekapt. Het ligt dus echt aan de error-log.

Ik zie in de nginx.conf de onderstaande regels:

fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log warn;

Die "access_log" stond voorheen dus op "off".

[Wmm]

Een wilde gok: crasht PHP oid op de momenten dat het afgekapt wordt? Op het moment van crash is dan nog niet alle data naar de file geflushed en echt weggeschreven. Heb zoiets op Windows machines met .NET programmas meegemaakt, geen idee hoe het op Nginx/PHP werkt.

[Kevin-de-Groot]

Niet dat ik zo kan zien. Maar er worden ook veel (lees: erg veel) errors gelogd. Waarschijnlijk zit er een grote loop met daarin allemaal errors, want als ik de pagina vernieuw, zie ik veel dezelfde errors voorbij komen.

Tja, misschien komt het doordat er zoveel errors zijn? Meer errors (per seconde) dan dat er weg kan worden geschreven, zeg maar.

Ik denk dat het verstandig is om eerst zoveel mogelijk terugkomende (en/of herhaalde) errors te verhelpen. Dat heb ik al gedaan, maar dan ga ik daar nu weer mee verder. Misschien dat het dan wél goed gaat.

Bedankt voor het meedenken

Edit: wat ik er nog bij wilde vermelden is dat zo'n 5 (maximaal 10) procent van de errors incompleet (afgekapt) zijn. Bij elke refresh van de pagina zit er eigenlijk wel zo'n afgekapte error tussen. Dat zou dus betekenen dat PHP bij elk bezoek van de pagina crasht. Ik hoop het niet

[ Voor 19% gewijzigd door Kevin-de-Groot op 26-01-2017 08:27 ]

[Swedish Clown]

Ik doe maar even een wilde gok, maar had je deze Stackoverflow post al gevonden?

http://stackoverflow.com/...ror-log-getting-truncated

[.Maarten]

Fix eerst het merendeel van je errors en ga daarna eens kijken waarom je errorlog zo raar doet.

[Kevin-de-Groot]

@Brakkie41 Ik had die post al gelezen, maar ik denk dat dat niet voor mijn geval opgaat. Sommige regels zijn écht kort/klein, zoals dit:

PHP message: PHP Notice: Ar

@.Maarten Ja, daar was ik al mee bezig. Ik ga daar ook weer mee bezig. Maar ik hoopte dat iemand mij duidelijk kon maken waarom dit gebeurt. Vanzelfsprekend moeten eigenlijk alle errors verholpen worden. Ik schrok daarom ook wel een beetje van de logs

[martijncalker]

Wat was het resultaat om php naar een file te laten loggen? Werkte dat niet? En uit welke log-file komen je huidige errors?

[Kevin-de-Groot]

Ik heb bovenin het bestand (waar de errors in zaten) het volgende geplaatst:

code:

error_reporting(E_ALL & ~E_STRICT & ~E_DEPRECATED);
ini_set('display_errors', 1);

ini_set('log_errors', 1);
ini_set('error_log', '/var/log/nginx/php-errors.log');

En hier komen dusver geen rare errors in voor. Althans, geen afgekapte. Ik ga deze code even in een algemeen bestand zetten zodat dit voor de hele site werkt. Want misschien worden die afgekapte errors wel in een ander bestand gegenereerd.

Onderstaande regels komen uit phpinfo, misschien dat je er wat aan hebt:

GENERAL

System Linux <SERVER_NAME> 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64
Server API FPM/FastCGI
Configuration File (php.ini) Path /etc/php5/fpm
Loaded Configuration File /etc/php5/fpm/php.ini
Scan this dir for additional .ini files /etc/php5/fpm/conf.d

CGI-FCGI

php-fpm active
fastcgi.logging 1
fpm.config no value

CORE

error_log no value
error_reporting 32767 (master value: 22527)

log_errors On
log_errors_max_len 1024

Edit: ik heb de regels toegevoegd aan een algemeen bestand en ik zie in het nieuw aangemaakte error-bestand geen afgekapte regels. Dus die afgekapte errors worden door iets anders gegenereerd.

Edit 2: is het uitschakelen van errors in NGINX geen oplossing? Zolang ik mijn PHP errors maar log (zoals ik nu doe), dan is het toch goed? Want op dit moment logt 'ie alles 2 keer. Of is dat een beetje "negeren"

[ Voor 14% gewijzigd door Kevin-de-Groot op 26-01-2017 10:52 ]