I can guarantee you, I am not the only person who has been driven to madness at least once in a frustrating search for a log file. It seems like it should be the easiest thing to find in the whole system.
A definitive guide on where the PHP error log is stored would be a complicated bit of work. The official PHP manual does not even try to address the whole topic, because there are dependencies on systems outside PHP, such as the operating system (Linux vs. Windows, which distribution of Linux), including settings within Windows and Linux that affect the name and location of the PHP error log.
Until someone takes the time to write a complete, cross-system guide, the best you are going to get is general directions where you can inquire. Every PHP developer has had to endure agony in this pursuit, with one exception. If you work in one place and the information is provided when you first need it, then you have the information need forever, that is, until you find yourself in a new working environment. There are such fortunate people.
If the information is not given to you on a silver platter, so to speak, you have some hunting to do. The hunt is not the longest you will face in your career, but it is not the simplest either.
As is evident from the many answers already posted, a smart place to begin is the output of phpinfo(). To view it, create a PHP file containing this:
<?php
phpinfo();
Either browse to that file or run it from the command line. If you do both, you likely will find the error_log is in different places, depending on command line vs. web server use of PHP. That is because the PHP interpreter that runs on a web server is not the same PHP interpreter that runs from the command line, even when the command line is on the same machine as the web server. The answers already posted in here mostly are making an unstated assumption that PHP is running as part of a web server.
The default for error_log is no value
Whatever the value is, it comes from the php.ini files used to configure PHP. There can be many php.ini files. Finding your way among them is confusing at first, but you do not need to deal with this to find your PHP log.
If the output from phpinfo() shows a full path to a file, that is where the log is. You are lucky.
The trick is there usually is not a full path indicated in phpinfo(). When there is not a full path, the location depends on:
-
Whether error_log is no value. If it is, the log file location will depend on the operating system and the mode PHP is running. If PHP is running as an Apache module, on Linux the log often is in /var/log/apache2/error.log. Another likely spot is in a logs directory in your account home directory, ~/logs/error.log.
-
If there is a file name without a path, the location depends on whether the file name has the value syslog. If it syslog, then the PHP error log is injected into the syslog for the server, which varies by Linux distribution. A common location is /var/log/syslog, but it can be anywhere. Even the name of the syslog varies by distribution.
-
If the name without a path is not syslog, a frequent home for the file is is the document root of the website (a.k.a., website home directory, not to be confused with the home directory for your account).
This cheat sheet has been helpful in some situations, but I regret to have to admit it is not nearly universal. You have my condolences.
Where are PHP Errors Logged?
So when we encounter errors in our code, where exactly can we find them? At a high level, there are really only three places where PHP errors can be found: inline with program execution, in the system log, or in error monitoring tools like Rollbar.
Inline errors
By default, whenever an error or exception is thrown, PHP sends the error message directly to the user via STDOUT. In a command-line environment, this means that errors are rendered in the terminal. In a web environment, errors and exceptions get displayed directly in the browser.
While this behavior is useful for debugging problems in a development environment, it should be disabled in a production environment for security reasons. To do this, open up the PHP configuration file for the environment you are working in—typically found in a path that looks like /etc/php/:environment:/php.ini—and change the display_errors directive to Off.
; 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 = OnLog files
While rendering errors to STDOUT is great for debugging issues in a development environment as they happen, it isn’t very useful in a production environment. This is where the error log comes into play. By default, PHP doesn’t log any errors, which means that this value must be explicitly set. To do so, open up the same PHP configuration file referenced above in your favorite editor and find the error_log directive.
; 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 = syslogThere are two possible values for error_log: a custom log file and the syslog. If the syslog is used, then all PHP errors will be sent directly to the default system log file—in Linux, this is typically /var/log/syslog. The more manageable method is to use a custom log file. By doing this, you can isolate your PHP application’s logs from the rest of the system logs, which can make debugging issues significantly easier.
Logging in Laravel
While PHP’s default system logger is useful for bespoke applications, it is important to note that many application frameworks provide their own built-in logging mechanisms. A great example of this is the Laravel framework. In Laravel, the logging method can be changed within the log option of the application configuration file—found in config/app.php.
/*
|--------------------------------------------------------------------------
| Logging Configuration
|--------------------------------------------------------------------------
|
| Here you may configure the log settings for your application. Out of
| the box, Laravel uses the Monolog PHP logging library. This gives
| you a variety of powerful log handlers / formatters to utilize.
|
| Available Settings: "single", "daily", "syslog", "errorlog"
|
*/
'log' => env('APP_LOG', 'single'),By default, Laravel maintains a single log file at storage/logs/laravel.log within the project directory, rather than the defined error_log option from the global PHP configuration.
Logging in Symfony
Because Laravel is built on top of Symfony, they share the same core logging mechanism—although the configuration differs between the two frameworks. Logging in Symfony and Laravel are both done using Monolog, a third-party PHP logging library that can be used to create and store logs in a large number of ways.
By default, Symfony logs are stored in var/log/dev.log and var/log/prod.log within the project directory, depending on the environment, but these defaults can be changed in the Monolog package configuration file found at config/packages/monolog.php.
$container->loadFromExtension('monolog', array(
'handlers' => array(
'file_log' => array(
'type' => 'stream',
'path' => '%kernel.logs_dir%/%kernel.environment%.log',
'level' => 'debug',
),
'syslog_handler' => array(
'type' => 'syslog',
'level' => 'error',
),
),
));What do PHP logs look like?
So, what exactly do PHP logs look like? In most instances, PHP logs follow a fairly predictable format:
Dec 10 04:04:38 scotchbox apache2: PHP Parse error: syntax error, unexpected end of file in /var/www/public/index2.php on line 4In a nutshell, the log line above can be broken up into four parts: the date, the hostname, the process, and the error message. Whenever an error is encountered or an uncaught exception is thrown, the error message is printed along with the date, hostname, and process metadata to help pinpoint what happened, where it happened, and when it happened.
A primer on log levels
It is important to note that, in PHP, there are a handful of log levels that can be squashed or raised. While these log levels are determined by PHP itself, understanding what they are and mean is a crucial step towards being able to diagnose problems as they happen.
When display_errors is set to On, it can be useful to explicitly hide and show specific log levels so you can focus on one task at a time, such as critical errors, or cleaning up warnings. This can be accomplished using the built-in error_reporting method.
// Report simple running errors
error_reporting(E_ERROR | E_WARNING | E_PARSE);
// Report all errors except E_NOTICE
error_reporting(E_ALL & ~E_NOTICE);This method accepts an integer value that tells PHP which errors to display, and which ones to ignore. Through the use of bitwise operators (| meaning OR, & meaning AND, and ~ meaning NOT), we can clearly and easily define which errors we want to see.
Here are a few of the most common log levels. For more information about log levels (there are quite a few of them), take a look at PHP’s official documentation.
| Error Level | Description |
|---|---|
| E_ERROR | Fatal run-time errors. These indicate errors that can not be recovered from, such as a memory allocation problem. Execution of the script is halted. |
| E_WARNINIG | Run-time warnings (non-fatal errors). Execution of the script is not halted. |
| E_PARSE | Compile-time parse errors. Parse errors should only be generated by the parser. |
| E_NOTICE | Run-time notices. These indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script. |
Как посмотреть логи PHP
Логи PHP — это важный инструмент для отслеживания ошибок и предупреждений, возникающих во время работы вашего веб-приложения. В этой статье мы рассмотрим, как найти и просмотреть логи PHP на вашем сервере.
1. Определение местоположения логов PHP
Вам необходимо знать, где хранятся логи PHP на вашем сервере. Местоположение файла логов зависит от конфигурации вашего сервера и операционной системы. Обычно файлы логов PHP находятся в следующих директориях:
- Для Linux:
/var/log/php_errors.logили/var/log/httpd/error_log - Для Windows (WAMP, XAMPP):
C:\wamp\logs\php_error.logилиC:\xampp\php\logs\php_error_log
Вы также можете проверить значение директивы error_log в файле конфигурации php.ini для определения местоположения файла логов на вашем сервере:
error_log = /path/to/your/php_error.log2. Просмотр логов PHP
После того как вы определили местоположение файла логов PHP, вы можете просмотреть его содержимое. В зависимости от вашего предпочтения и доступных инструментов, вы можете использовать различные методы:
- С помощью текстового редактора (Notepad, Vim, Nano и т.д.)
- С помощью командной строки (например, команда
tailв Linux) - С помощью FTP-клиента (если логи находятся на удаленном сервере)
- С помощью специализированных инструментов для просмотра логов
3. Разбор ошибок и предупреждений в логах
При просмотре логов PHP, обратите внимание на типы сообщений об ошибках и предупреждениях. Это поможет вам определить причину возникновения проблемы и разработать стратегию ее решения. Вот некоторые типы ошибок и предупреждений, которые могут встретиться в логах PHP:
- Parse error — синтаксическая ошибка в коде, которую необходимо исправить;
- Fatal error — критическая ошибка, которая приводит к остановке выполнения скрипта;
- Warning — предупреждение о потенциальной проблеме, которое не останавливает выполнение скрипта, но может вызвать нежелательное поведение;
- Notice — уведомление о возможной проблеме, которая не влияет на работу скрипта, но может указывать на проблемы в коде или настройках сервера.
4. Исправление ошибок и предупреждений
После того как вы определили тип ошибки или предупреждения, вы можете приступить к исправлению проблемы. В большинстве случаев, вам придется изменить исходный код вашего веб-приложения. Возможно, потребуется также настроить сервер или обновить используемые библиотеки и компоненты.
Если вы испытываете трудности с определением причины ошибки или предупреждения, обратитесь к документации PHP, форумам, сообществам разработчиков или коллегам, которые могут помочь вам с разбором проблемы и предложить решение.
5. Мониторинг логов PHP
Регулярное просматривание логов PHP поможет вам оперативно обнаруживать и исправлять ошибки и предупреждения, возникающие в вашем веб-приложении. Вы также можете использовать специализированные инструменты и сервисы для мониторинга логов, которые автоматизируют процесс сбора, анализа и оповещения о возникающих проблемах.
Теперь вы знаете, как найти и просмотреть логи PHP на вашем сервере, а также как разбираться с ошибками и предупреждениями. Это поможет вам поддерживать стабильную и безопасную работу вашего веб-приложения.
Vitaily
А если в php.ini прописан этот файл так, как вы здесь указали (и phpinfo() выводит это), стоят права на этот файл 644 (rw-r—r—), пользователем установлен www-data, но логирование в этот файл не происходит? Апач перегружен несколько раз…
Что может быть сделано не так?
Reply
admin
Апач в процессах работает от этого пользователя?
LOG_ERRORS = 1, так же попробуйте изменить уровень логирования. Проверьте права на паку выше.
Reply
The behaviour of these functions is affected by settings in php.ini.
| Name | Default | Changeable | Changelog |
|---|---|---|---|
| error_reporting | NULL | PHP_INI_ALL | |
| display_errors | «1» | PHP_INI_ALL | |
| display_startup_errors | «1» | PHP_INI_ALL |
Prior to PHP 8.0.0, the default value was "0".
|
| log_errors | «0» | PHP_INI_ALL | |
| log_errors_max_len | «1024» | PHP_INI_ALL | Had no effect as of PHP 8.0.0, removed as of PHP 8.1.0. |
| ignore_repeated_errors | «0» | PHP_INI_ALL | |
| ignore_repeated_source | «0» | PHP_INI_ALL | |
| report_memleaks | «1» | PHP_INI_ALL | |
| track_errors | «0» | PHP_INI_ALL | Deprecated as of PHP 7.2.0, removed as of PHP 8.0.0. |
| html_errors | «1» | PHP_INI_ALL | |
| xmlrpc_errors | «0» | PHP_INI_SYSTEM | |
| xmlrpc_error_number | «0» | PHP_INI_ALL | |
| docref_root | «» | PHP_INI_ALL | |
| docref_ext | «» | PHP_INI_ALL | |
| error_prepend_string | NULL | PHP_INI_ALL | |
| error_append_string | NULL | PHP_INI_ALL | |
| error_log | NULL | PHP_INI_ALL | |
| error_log_mode | 0o644 | PHP_INI_ALL | Available as of PHP 8.2.0 |
| syslog.facility | «LOG_USER» | PHP_INI_SYSTEM | Available as of PHP 7.3.0. |
| syslog.filter | «no-ctrl» | PHP_INI_ALL | Available as of PHP 7.3.0. |
| syslog.ident | «php» | PHP_INI_SYSTEM | Available as of PHP 7.3.0. |
For further details and definitions of the
PHP_INI_* modes, see the Where a configuration setting may be set.
Here’s a short explanation of
the configuration directives.
-
error_reporting
int -
Set the error reporting level. The parameter is either an integer
representing a bit field, or named constants. The error_reporting
levels and constants are described in
Predefined Constants,
and in php.ini. To set at runtime, use the
error_reporting() function. See also the
display_errors directive.The default value is
E_ALL.Prior to PHP 8.0.0, the default value was:
E_ALL&
~E_NOTICE&
~E_STRICT&
~E_DEPRECATED
This means diagnostics of levelE_NOTICE,
E_STRICTandE_DEPRECATED
were not shown.Note:
PHP Constants outside of PHPUsing PHP Constants outside of PHP, like in httpd.conf,
will have no useful meaning so in such cases the int values
are required. And since error levels will be added over time, the maximum
value (forE_ALL) will likely change. So in place of
E_ALLconsider using a larger value to cover all bit
fields from now and well into the future, a numeric value like
2147483647(includes all errors, not just
E_ALL). -
display_errors
string -
This determines whether errors should be printed to the screen
as part of the output or if they should be hidden from the user.Value
"stderr"sends the errors tostderr
instead ofstdout.Note:
This is a feature to support your development and should never be used
on production systems (e.g. systems connected to the internet).Note:
Although display_errors may be set at runtime (with ini_set()),
it won’t have any effect if the script has fatal errors.
This is because the desired runtime action does not get executed. -
display_startup_errors
bool -
Even when display_errors is on, errors that occur during PHP’s startup
sequence are not displayed. It’s strongly recommended to keep
display_startup_errors off, except for debugging. -
log_errors
bool -
Tells whether script error messages should be logged to the
server’s error log or error_log.
This option is thus server-specific.Note:
You’re strongly advised to use error logging in place of
error displaying on production web sites. -
log_errors_max_len
int -
Set the maximum length of log_errors in bytes. In
error_log information about
the source is added. The default is 1024 and 0 allows to not apply
any maximum length at all.
This length is applied to logged errors, displayed errors and also to
$php_errormsg, but not to explicitly called functions
such as error_log().When an int is used, the
value is measured in bytes. Shorthand notation, as described
in this FAQ, may also be used.
-
ignore_repeated_errors
bool -
Do not log repeated messages. Repeated errors must occur in the same
file on the same line unless
ignore_repeated_source
is set true. -
ignore_repeated_source
bool -
Ignore source of message when ignoring repeated messages. When this setting
is On you will not log errors with repeated messages from different files or
sourcelines. -
report_memleaks
bool -
If this parameter is set to On (the default), this parameter will show a
report of memory leaks detected by the Zend memory manager. This report
will be sent to stderr on Posix platforms. On Windows, it will be sent
to the debugger using OutputDebugString() and can be viewed with tools
like » DbgView.
This parameter only has effect in a debug build and if
error_reporting includesE_WARNINGin the allowed
list. -
track_errors
bool -
If enabled, the last error message will always be present in the
variable $php_errormsg. -
html_errors
bool -
If enabled, error messages will include HTML tags. The format for HTML
errors produces clickable messages that direct the user to a page
describing the error or function in causing the error. These references
are affected by
docref_root and
docref_ext.If disabled, error message will be solely plain text.
-
xmlrpc_errors
bool -
If enabled, turns off normal error reporting and formats errors as
XML-RPC error message. -
xmlrpc_error_number
int -
Used as the value of the XML-RPC faultCode element.
-
docref_root
string -
The new error format contains a reference to a page describing the error or
function causing the error. In case of manual pages you can download the
manual in your language and set this ini directive to the URL of your local
copy. If your local copy of the manual can be reached by"/manual/"
you can simply usedocref_root=/manual/. Additional you have
to set docref_ext to match the fileextensions of your copy
docref_ext=.html. It is possible to use external
references. For example you can use
docref_root=http://manual/en/or
docref_root="http://landonize.it/?how=url&theme=classic&filter=Landon
&url=http%3A%2F%2Fwww.php.net%2F"Most of the time you want the docref_root value to end with a slash
"/".
But see the second example above which does not have nor need it.Note:
This is a feature to support your development since it makes it easy to
lookup a function description. However it should never be used on
production systems (e.g. systems connected to the internet). -
docref_ext
string -
See docref_root.
Note:
The value of docref_ext must begin with a dot
".". -
error_prepend_string
string -
String to output before an error message.
Only used when the error message is displayed on screen. The main purpose
is to be able to prepend additional HTML markup to the error message. -
error_append_string
string -
String to output after an error message.
Only used when the error message is displayed on screen. The main purpose
is to be able to append additional HTML markup to the error message. -
error_log
string -
Name of the file where script errors should be logged. The file should
be writable by the web server’s user. If the
special valuesyslogis used, the errors
are sent to the system logger instead. On Unix, this means
syslog(3) and on Windows it means the event log. See also:
syslog().
If this directive is not set, errors are sent to the SAPI error logger.
For example, it is an error log in Apache orstderr
in CLI.
See also error_log(). -
error_log_mode
int -
File mode for the file described set in
error_log. -
syslog.facility
string -
Specifies what type of program is logging the message.
Only effective if error_log is set to «syslog». -
syslog.filter
string -
Specifies the filter type to filter the logged messages. Allowed
characters are passed unmodified; all others are written in their
hexadecimal representation prefixed with\x.-
all– the logged string will be split
at newline characters, and all characters are passed unaltered
-
ascii– the logged string will be split
at newline characters, and any non-printable 7-bit ASCII characters will be escaped
-
no-ctrl– the logged string will be split
at newline characters, and any non-printable characters will be escaped
-
raw– all characters are passed to the system
logger unaltered, without splitting at newlines (identical to PHP before 7.3)
This setting will affect logging via error_log set to «syslog» and calls to syslog().
Note:
The
rawfilter type is available as of PHP 7.3.8 and PHP 7.4.0.
This directive is not supported on Windows.
-
-
syslog.ident
string -
Specifies the ident string which is prepended to every message.
Only effective if error_log is set to «syslog».
cjakeman at bcs dot org ¶
14 years ago
Using
<?php ini_set('display_errors', 1); ?>
at the top of your script will not catch any parse errors. A missing ")" or ";" will still lead to a blank page.
This is because the entire script is parsed before any of it is executed. If you are unable to change php.ini and set
display_errors On
then there is a possible solution suggested under error_reporting:
<?php
error_reporting(E_ALL);
ini_set("display_errors", 1);
include("file_with_errors.php");
?>
[Modified by moderator]
You should also consider setting error_reporting = -1 in your php.ini and display_errors = On if you are in development mode to see all fatal/parse errors or set error_log to your desired file to log errors instead of display_errors in production (this requires log_errors to be turned on).
ohcc at 163 dot com ¶
6 years ago
If you set the error_log directive to a relative path, it is a path relative to the document root rather than php's containing folder.
iio7 at protonmail dot com ¶
1 year ago
It's important to note that when display_errors is "on", PHP will send a HTTP 200 OK status code even when there is an error. This is not a mistake or a wrong behavior, but is because you're asking PHP to output normal HTML, i.e. the error message, to the browser.
When display_errors is set to "off", PHP will send a HTTP 500 Internal Server Error, and let the web server handle it from there. If the web server is setup to intercept FastCGI errors (in case of NGINX), it will display the 500 error page it has setup. If the web server cannot intercept FastCGI errors, or it isn't setup to do it, an empty screen will be displayed in the browser (the famous white screen of death).
If you need a custom error page but cannot intercept PHP errors on the web server you're using, you can use PHPs custom error and exception handling mechanism. If you combine that with output buffering you can prevent any output to reach the client before the error/exception occurs. Just remember that parse errors are compile time errors that cannot be handled by a custom handler, use "php -l foo.php" from the terminal to check for parse errors before putting your files on production.
Roger ¶
4 years ago
When `error_log` is set to a file path, log messages will automatically be prefixed with timestamp [DD-MMM-YYYY HH:MM:SS UTC]. This appears to be hard-coded, with no formatting options.
php dot net at sp-in dot dk ¶
8 years ago
There does not appear to be a way to set a tag / ident / program for log entries in the ini file when using error_log=syslog. When I test locally, "apache2" is used.
However, calling openlog() with an ident parameter early in your script (or using an auto_prepend_file) will make PHP use that value for all subsequent log entries. closelog() will restore the original tag.
This can be done for setting facility as well, although the original value does not seem to be restored by closelog().
jaymore at gmail dot com ¶
6 years ago
Document says
So in place of E_ALL consider using a larger value to cover all bit fields from now and well into the future, a numeric value like 2147483647 (includes all errors, not just E_ALL).
But it is better to set "-1" as the E_ALL value.
For example, in httpd.conf or .htaccess, use
php_value error_reporting -1
to report all kind of error without be worried by the PHP version.