web-dev-qa-db-fra.com

PHP CLI ne journalisera pas les erreurs

PHP n'enregistre actuellement pas les erreurs produites à partir de la ligne de commande.

J'ai :

log_errors = On
error_log = /var/log/php_errors.log

dans /etc/php5/cli/php.ini

Me manque-t-il un autre paramètre pour que cela fonctionne?

phpcommand-line-interfaceerror-logging
39
bcmcfc

Veuillez vérifier que le compte utilisateur exécutant PHP CLI dispose d'un accès en écriture à /var/log/php_errors.log.

De plus, vous pouvez vérifier que vous utilisez le bon fichier php.ini comme ceci:

php -a -c /etc/php5/cli/php.ini
40
George Cummins

Ce fil de questions et réponses m'a été très utile lors de la configuration de PHP CLI se connectant sur un environnement Ubuntu 12.04, donc je voulais publier une réponse qui distille ce que j'ai appris. En plus des informations utiles fourni par David Chan ainsi que George Cummins J'ai créé un logrotate.d script pour garantir que le PHP journal des erreurs CLI ne se développe pas de façon incontrôlée ainsi que le configurer afin que plusieurs utilisateurs puissent consigner les erreurs dans le PHP Journal des erreurs CLI.

Tout d'abord, le comportement par défaut de la CLI PHP consiste à enregistrer les messages d'erreur sur la sortie standard; la journalisation dans un fichier n'est pas un comportement par défaut. Ce qui signifie généralement la connexion à la même session de terminal de ligne de commande qui est en cours d'exécution la commande CLI PHP. Alors que le fichier ini PHP contient des adaptations pour un error_log des aménagements supplémentaires doivent être faits pour que cela fonctionne vraiment.

J'ai d'abord dû créer une première php_errors.log fichier:

Sudo touch /var/log/php_errors.log

Étant donné que le serveur en question est utilisé par des développeurs Web travaillant sur divers projets, j'ai configuré pour eux un groupe commun appelé www-users. Et dans ce cas, je veux que le php_errors.log à lire et à écrire par www-users Je change la propriété du fichier comme ceci:

Sudo chown root:www-users /var/log/php_errors.log

Et puis changez les autorisations du fichier en ceci:

Sudo chmod 664 /var/log/php_errors.log

Oui, du point de vue de la sécurité, avoir un fichier journal lisible et accessible en écriture par quiconque dans www-users n'est pas si génial. Mais il s'agit d'un environnement de travail partagé contrôlé. Je fais donc confiance aux utilisateurs pour respecter des choses comme ça. Et en outre, lorsque PHP est exécuté à partir de la CLI, tout utilisateur qui peut le faire devra de toute façon avoir un accès en écriture aux journaux pour même obtenir un journal écrit.

Ensuite, allez dans /etc/php5/cli/php.ini pour ajuster les paramètres par défaut d'Ubuntu 12.04 afin qu'ils correspondent à ce nouveau fichier journal:

Sudo nano /etc/php5/cli/php.ini

Heureusement log_errors est activé par défaut dans Ubuntu 12.04:

log_errors = On

Mais pour permettre la journalisation dans un fichier, nous devons modifier le error_log pour faire correspondre le nouveau fichier comme ceci:

error_log = /var/log/php_errors.log

Mettre en place un logrotate.d script.

Cela devrait être le cas, mais comme je ne veux pas que les journaux soient hors de contrôle, j'ai défini un logrotate.d pour le php_errors.log. Créez un fichier appelé php-cli dans /etc/logrotate.d/ comme ça:

Sudo nano /etc/logrotate.d/php-cli

Et placez le contenu de ce script de démon de rotation de journal dedans:

/var/log/php_errors.log {
        weekly
        missingok
        rotate 13
        compress
        delaycompress
        copytruncate
        notifempty
        create 664 root www-users
        sharedscripts
}

Test de la configuration.

Cela fait, testons la configuration à l'aide de David Chan conseil ci-dessus:

php -r "error_log('This is an error test that we hope works.');"

Si cela s'est déroulé correctement, vous devriez simplement être renvoyé à une invite de commande vide car PHP CLI ne sont plus envoyées à la sortie standard. Vérifiez donc le réel php_errors.log pour le message d'erreur de test comme ceci:

tail -n 10 /var/log/php_errors.log

Et il devrait y avoir une ligne d'erreur horodatée qui ressemble à ceci:

[23-Jul-2014 16:04:56 UTC] This is an error test that we hope works.
31
JakeGould

comme diagnostic, vous pouvez essayer de forcer une écriture dans le journal des erreurs de cette façon.

php -c /etc/php5/cli/php.ini -r " error_log('test 123'); "

vous devriez maintenant voir le test 123 dans votre journal

tail /var/log/php_errors.log
15
David Chan

Le comportement de journalisation/rapport de PHP dépend aussi de error_reporting.

Certains frameworks PHP (par exemple CodeIgniter) exécutent une instruction error_reporting(E_STRICT) ou équivalent, en mode production, ce qui réduira considérablement le nombre/type d'erreurs consignées.

Si vous souhaitez déboguer quelque chose, vous pouvez simplement placer l'instruction suivante juste avant votre code:

error_reporting(E_ALL);
3
Dangelov

Si vous ne pouvez pas comprendre pourquoi ou si vous n'avez peut-être pas d'autorisations utilisateur sur php.ini, une autre façon de déboguer une erreur d'analyse sans information consiste à envelopper votre source php dans une autre source php avec un corps comme:

ini_set('display_errors',1);
error_reporting(E_ALL);

include "mybustedfile.php";
2
Charlie

dans PHP

error_log("You messed up!", 3, "/var/tmp/my-errors.log");

dans le terminal

tail -f /var/tmp/my-errors.log

sortie Vous avez foiré!

1
Saurabh Chandra Patel