2009-07-29 29 views
15

¿Cuál es la configuración de configuración de PHP que permite o impide que se escapen las nuevas líneas en la salida de depuración?Registro de errores de PHP y caracteres de nueva línea

En dos instalaciones diferentes (un equipo portátil dev que ejecuta MAMP/OSX y un servidor de desarrollo ejecutando Debian) veo resultados diferentes en los registros de errores cuando se depura.

error_log(print_r(array(1,2,4),1)); 

En Debian esto aparece en /var/log/apache2/error.log como

[Thu Jul 30 11:32:34 2009] [error] [client 118.93.246.104] Array\n(\n [0] => 1\n [1] => 2\n [2] => 4\n)\n, referer: http://dev.example.org/ 

en OSX esto aparece en/Aplicaciones/MAMP/logs/php_error_log como

[30-Jul-2009 11:34:00] Array 
(
    [0] => 1 
    [1] => 2 
    [2] => 4 
) 

Prefiero el modo MAMP para la depuración (aparte de la reubicación de archivos de registro en el directorio/Aplicaciones).

Gracias!

Respuesta

12

Chris, deberías poder cambiar la directiva error_log en tu php.ini en Debian para que apunte a un archivo. Si no está definido, pasará por syslog, que no admite múltiples líneas.

Detalles:

error_log función

error_log Directiva

+0

También se debe mencionar que si el usuario que Apache ejecuta no puede escribir en el archivo error_log especificado (debido a problemas de permisos), también irá a syslog o al registro de Apache. – Pistos

-2

me ocurrió una buena solución para esto y simplemente escribió en su blog al respecto, podrían ser útiles para las personas: http://www.drcoen.com/2012/05/php-error_log-and-newlines-a-solution/. TL; DR: escribe en un archivo que creas en/tmp, escribe una función que escribe tu información de depuración en ese archivo y también enruta el registro de Apache (para que no tengas que rastrear 2 archivos de error).

+0

Gracias. AFAICT esto es más o menos "trabajar alrededor de las restricciones de permisos creando un nuevo archivo en/tmp"; la pista de permisos de @Pistos arriba era el ingrediente que faltaba para mí al final. –

+0

El enlace está desactivado y la respuesta no contiene instrucciones detalladas, lamentablemente. – Innovaat

+1

Aquí está el último enlace, no se dio cuenta de que había cambiado: http://www.drcoen.com/2012/05/php-error_log-and-newlines-a-solution/ Se siente duro al conseguir un voto negativo, será útil si no puede resolver el problema original, lo que no pude hacer (de ahí la solución). – eclipse31

2

El problema se produce cuando el proceso de Apache no puede escribir en el archivo error_log, por lo que el syslog escribe en el archivo. El syslog arruina los saltos de línea.

Así que sólo lo hacen:

chmod 777 error.log 

Esto debería resolver su problema.

+3

Desconfíe de establecer go + x en un archivo en el que los atacantes pueden escribir. Establezca en su lugar la lectura/escritura grupal y la propiedad del grupo en el usuario del servidor web. Tenga cuidado con los cambios de permisos al deshacerse de la rotación de registros (configuración de chmod en la configuración de logrotate, etc.). –

+0

Estoy de acuerdo en que esto es algo inseguro (aunque espero que sus archivos de registro no sean accesibles a través del servidor web ...) pero es muy rápido para un entorno de desarrollo local y señala el problema clave, que es que los permisos de el archivo de registro puede evitar que Apache escriba en él, lo que provoca que se use syslog en su lugar. –

+1

Mi propia solución era más como la recomendación de Chris Burgess, agregué mi usuario al grupo en el que se ejecuta el servidor web, cambié los permisos del archivo para permitir el acceso total al grupo y cambié la propiedad del archivo al usuario/grupo que el servidor web ejecuta , es decir, en OSX con el Apache preinstalado: '' 'sudo dseditgroup -o edit -a myusername -t user _www; sudo chown _www: _www/var/log/apache2/error_log; sudo chmod 770/var/log/apache2/error_log; '' ' –

Cuestiones relacionadas