Error Reporting Itself
ini_set('display_errors', 1);
or display_errors
Simply allows PHP to output errors — useful for debugging, highly recommended to disable for production environments. It often contains information you’d never want users to see.
error_reporting(E_ALL);
or error_reporting
Simply sets exactly which errors are shown.
Setting one or the other will not guarantee that errors will be displayed. You must set both to actually see errors on your screen.
As for setting this up permanently inside your PHP config, the default for error_reporting
is E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED. That said, this variable should not need changed. See here:
http://php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
As for displaying errors, see here:
http://php.net/manual/en/errorfunc.configuration.php#ini.display-errors
Set the config value of «display_errors» to either stderr
or stdout
, depending on your need.
Just change these variables inside of your php.ini
file and you’ll be golden. Make absolutely sure both display_errors
and error_reporting
is set to a satisfactory value. Just setting error_reporting
will not guarantee that you see the errors you’re looking for!
Error Reporting Works Everywhere Except When Connecting To My DB!
If you see errors everywhere you need to except in the Database Connection, you just need to do some error catching. If it’s PDO, do something like this:
try {
$this->DBH->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
$this->DBH->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$STH = $this->DBH->prepare("INSERT INTO `" . $this->table . "` ($fs) value ($ins) $up");
$STH->execute($data);
$id = $this->DBH->lastInsertId();
$this->closeDb();
return $id;
} catch(PDOException $e) {
echo $e->getMessage();
}
Just a snippet from my framework. Of course you’ll have to change it to your liking, but you should be able to get the general idea there. They key is this part here:
try {
//DB Stuff
} catch(PDOException $e) {
echo $e->getMessage();
}
I Still Don’t See The Error
If you’ve done both of what I’ve listed here and still have trouble, your problem has nothing to do with enabling error reporting. The code provided will show you the error with a Database Connection itself, and inside of PHP code. You must have a completely different issue if this has not shown you an error you’re chasing.
You’ll likely need to be a bit more descriptive on exactly what you’re chasing, and what you’re expecting to see.
Блог / Программирование / Настроить Nginx для вывода php ошибок в браузер (а не только в log)
Это не является настройкой nginx, а управляется из конфигурации php-fpm.
Настройте в файле php-fpm.conf (к примеру для 7.4 это /etc/php/7.4/fpm/php-fpm.conf):
php_flag[display_errors] = on php_flag[display_startup_errors] = on |
Написать комментарий
Данная запись опубликована в 07.04.2022 15:30 и размещена в Программирование.
Вы можете перейти в конец страницы и оставить ваш комментарий.
Мало букафф? Читайте есчо !
Авторизация по номеру телефона в Drupal
Октябрь 28, 2015 г.
Распространение сотовой связи сделало уместным идентификацию пользователя по номеру телефона. Этот номер стал на ряду с логином и адресом электронной почты …
Читать
Где взять CLI клиент jenkins
Февраль 18, 2022 г.
Если нет возможности подключиться к jenkins через web-интерфейс удаленно, то команды можно выполнять через CLI клиент локально. Но где его взять?
…
Читать
В этом руководстве мы расскажем о различных способах того, как в PHP включить вывод ошибок. Мы также обсудим, как записывать ошибки в журнал (лог).
Как быстро показать все ошибки PHP
Самый быстрый способ отобразить все ошибки и предупреждения php — добавить эти строки в файл PHP:
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
Что именно делают эти строки?
Функция ini_set попытается переопределить конфигурацию, найденную в вашем ini-файле PHP.
Display_errors и display_startup_errors — это только две из доступных директив. Директива display_errors определяет, будут ли ошибки отображаться для пользователя. Обычно директива dispay_errors не должна использоваться для “боевого” режима работы сайта, а должна использоваться только для разработки.
display_startup_errors — это отдельная директива, потому что display_errors не обрабатывает ошибки, которые будут встречаться во время запуска PHP. Список директив, которые могут быть переопределены функцией ini_set, находится в официальной документации .
К сожалению, эти две директивы не смогут отображать синтаксические ошибки, такие как пропущенные точки с запятой или отсутствующие фигурные скобки.
Отображение ошибок PHP через настройки в php.ini
Если ошибки в браузере по-прежнему не отображаются, то добавьте директиву:
display_errors = on
Директиву display_errors следует добавить в ini-файл PHP. Она отобразит все ошибки, включая синтаксические ошибки, которые невозможно отобразить, просто вызвав функцию ini_set в коде PHP.
Актуальный INI-файл можно найти в выводе функции phpinfo (). Он помечен как “загруженный файл конфигурации” (“loaded configuration file”).
Отображать ошибки PHP через настройки в .htaccess
Включить или выключить отображение ошибок можно и с помощью файла .htaccess, расположенного в каталоге сайта.
php_flag display_startup_errors on
php_flag display_errors on
.htaccess также имеет директивы для display_startup_errors и display_errors.
Вы можете настроить display_errors в .htaccess или в вашем файле PHP.ini. Однако многие хостинг-провайдеры не разрешают вам изменять ваш файл PHP.ini для включения display_errors.
В файле .htaccess также можно включить настраиваемый журнал ошибок, если папка журнала или файл журнала доступны для записи. Файл журнала может быть относительным путем к месту расположения .htaccess или абсолютным путем, например /var/www/html/website/public/logs
.
php_value error_log logs/all_errors.log
Включить подробные предупреждения и уведомления
Иногда предупреждения приводят к некоторым фатальным ошибкам в определенных условиях. Скрыть ошибки, но отображать только предупреждающие (warning) сообщения можно вот так:
error_reporting(E_WARNING);
Для отображения предупреждений и уведомлений укажите «E_WARNING | E_NOTICE».
Также можно указать E_ERROR, E_WARNING, E_PARSE и E_NOTICE в качестве аргументов. Чтобы сообщить обо всех ошибках, кроме уведомлений, укажите «E_ALL & ~ E_NOTICE», где E_ALL обозначает все возможные параметры функции error_reporting.
Более подробно о функции error_reporting ()
Функция сообщения об ошибках — это встроенная функция PHP, которая позволяет разработчикам контролировать, какие ошибки будут отображаться. Помните, что в PHP ini есть директива error_reporting, которая будет задана этой функцией во время выполнения.
error_reporting(0);
Для удаления всех ошибок, предупреждений, сообщений и уведомлений передайте в функцию error_reporting ноль. Можно сразу отключить сообщения отчетов в ini-файле PHP или в .htaccess:
error_reporting(E_NOTICE);
PHP позволяет использовать переменные, даже если они не объявлены. Это не стандартная практика, поскольку необъявленные переменные будут вызывать проблемы для приложения, если они используются в циклах и условиях.
Иногда это также происходит потому, что объявленная переменная имеет другое написание, чем переменная, используемая для условий или циклов. Когда E_NOTICE передается в функцию error_reporting, эти необъявленные переменные будут отображаться.
error_reporting(E_ALL & ~E_NOTICE);
Функция сообщения об ошибках позволяет вам фильтровать, какие ошибки могут отображаться. Символ «~» означает «нет», поэтому параметр ~ E_NOTICE означает не показывать уведомления. Обратите внимание на символы «&» и «|» между возможными параметрами. Символ «&» означает «верно для всех», в то время как символ «|» представляет любой из них, если он истинен. Эти два символа имеют одинаковое значение в условиях PHP OR и AND.
error_reporting(E_ALL);
error_reporting(-1);
ini_set('error_reporting', E_ALL);
Эти три строки кода делают одно и то же, они будут отображать все ошибки PHP. Error_reporting(E_ALL) наиболее широко используется разработчиками для отображения ошибок, потому что он более читабелен и понятен.
Включить ошибки php в файл с помощью функции error_log ()
У сайта на хостинге сообщения об ошибках не должны показываться конечным пользователям, но эта информация все равно должна быть записана в журнал (лог).
Простой способ использовать файлы журналов — использовать функцию error_log, которая принимает четыре параметра. Единственный обязательный параметр — это первый параметр, который содержит подробную информацию об ошибке или о том, что нужно регистрировать. Тип, назначение и заголовок являются необязательными параметрами.
error_log("There is something wrong!", 0);
Параметр type, если он не определен, будет по умолчанию равен 0, что означает, что эта информация журнала будет добавлена к любому файлу журнала, определенному на веб-сервере.
error_log("Email this error to someone!", 1, "someone@mydomain.com");
Параметр 1 отправит журнал ошибок на почтовый ящик, указанный в третьем параметре. Чтобы эта функция работала, PHP ini должен иметь правильную конфигурацию SMTP, чтобы иметь возможность отправлять электронные письма. Эти SMTP-директивы ini включают хост, тип шифрования, имя пользователя, пароль и порт. Этот вид отчетов рекомендуется использовать для самых критичных ошибок.
error_log("Write this error down to a file!", 3, "logs/my-errors.log");
Для записи сообщений в отдельный файл необходимо использовать тип 3. Третий параметр будет служить местоположением файла журнала и должен быть доступен для записи веб-сервером. Расположение файла журнала может быть относительным путем к тому, где этот код вызывается, или абсолютным путем.
Журнал ошибок PHP через конфигурацию веб-сервера
Лучший способ регистрировать ошибки — это определить их в файле конфигурации веб-сервера.
Однако в этом случае вам нужно попросить администратора сервера добавить следующие строки в конфигурацию.
Пример для Apache:
ErrorLog "/var/log/apache2/my-website-error.log"
В nginx директива называется error_log.
error_log /var/log/nginx/my-website-error.log;
Теперь вы знаете, как в PHP включить отображение ошибок. Надеемся, что эта информация была вам полезна.
When accessing some PHP scripts on my website, I’m getting the dreaded 500 error message. I’d like to know what’s wrong to fix it, but Nginx isn’t logging any PHP errors in the log file I have specified. This is my server block:
server {
listen 80;
server_name localhost;
access_log /home/whitey/sites/localhost/logs/access.log;
error_log /home/whitey/sites/localhost/logs/error.log error;
root /home/whitey/sites/localhost/htdocs;
index index.html index.php /index.php;
location / {
}
location ~ .php$ {
fastcgi_pass unix:/tmp/phpfpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
location ~* .(?:ico|css|js|gif|jpe?g|png)$ {
expires max;
}
}
Note that some PHP scripts work fine, and others don’t. So there isn’t a global problem with PHP, there’s just something in these scripts that’s causing Nginx to throw the 500 error.
How can I get to the bottom of this? The only thing in error.log
is an error about favicon.ico not being found.
asked Aug 13, 2012 at 18:30
4
You have to add the following to your php-fpm pool configurations:
catch_workers_output = 1
You have to add this line to each defined pool!
answered Aug 20, 2012 at 23:21
FleshgrinderFleshgrinder
3,7582 gold badges16 silver badges20 bronze badges
1
I had a similar issue.
I tried deploy phpMyAdmin with php-fpm 7.0 and nginx on CentOS7. Nginx showed me 500.html but there was not errors in any log file.
I did all of this
catch_workers_output = 1
and
display_errors = On
Either nginx log or php-fpm log did not contained any error string.
And when I commented this line in nginx.conf I was able to see in browser page things that was wrong.
# error_page 500 502 503 504 /50x.html;
# location = /50x.html {
# }
That was what helped me understand troubles.
answered Jul 13, 2017 at 12:20
venoelvenoel
1931 silver badge7 bronze badges
php-fpm
throws everything in /var/log/php5-fpm.log
or similar.
answered Aug 13, 2012 at 18:37
erickzettaerickzetta
5992 silver badges4 bronze badges
6
Look in your nginx.conf for an error_log
definition. Maybe nginx writes something in this error log.
You might also enable logging to file on PHP.
answered Aug 13, 2012 at 18:36
1
For me, this seemed to be a problem with upstart, which was routing the logs for php-fpm to it’s own custom location, e.g.:
/var/log/upstart/php5-fpm.log
There’s also some bugginess with ubuntu Precise, 12.04 that may contribute to the lack of logging ability: https://bugs.php.net/bug.php?id=61045 If you’re still running that version.
answered Jul 21, 2015 at 16:55
KzqaiKzqai
1,2784 gold badges18 silver badges32 bronze badges
When PHP display_errors are disabled, PHP errors can return Nginx 500 error.
You should take a look to your php-fpm logs, i’m sure you’ll find the error there. With CentOS 7 :
tail -f /var/log/php-fpm/www-error.log
You can also show PHP errors. In your php.ini, change :
display_errors = Off
to :
display_errors = On
Hope it helps.
answered Jan 22, 2016 at 0:34
This is what happened to me:
When I deleted my error log, nginx noticed that it was no longer missing. When I recreated this file nginx would no longer recognise that it existed, therefore not writing to the file.
To fix this, run these commands (I’m on Ubuntu 14.04 LTS):
sudo service nginx reload
If that doesn’t work, then try:
sudo service nginx restart
answered Aug 12, 2015 at 7:22
DanielDaniel
1111 silver badge3 bronze badges
4
Error Reporting Itself
ini_set('display_errors', 1);
or display_errors
Simply allows PHP to output errors — useful for debugging, highly recommended to disable for production environments. It often contains information you’d never want users to see.
error_reporting(E_ALL);
or error_reporting
Simply sets exactly which errors are shown.
Setting one or the other will not guarantee that errors will be displayed. You must set both to actually see errors on your screen.
As for setting this up permanently inside your PHP config, the default for error_reporting
is E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED. That said, this variable should not need changed. See here:
http://php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
As for displaying errors, see here:
http://php.net/manual/en/errorfunc.configuration.php#ini.display-errors
Set the config value of «display_errors» to either stderr
or stdout
, depending on your need.
Just change these variables inside of your php.ini
file and you’ll be golden. Make absolutely sure both display_errors
and error_reporting
is set to a satisfactory value. Just setting error_reporting
will not guarantee that you see the errors you’re looking for!
Error Reporting Works Everywhere Except When Connecting To My DB!
If you see errors everywhere you need to except in the Database Connection, you just need to do some error catching. If it’s PDO, do something like this:
try {
$this->DBH->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
$this->DBH->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$STH = $this->DBH->prepare("INSERT INTO `" . $this->table . "` ($fs) value ($ins) $up");
$STH->execute($data);
$id = $this->DBH->lastInsertId();
$this->closeDb();
return $id;
} catch(PDOException $e) {
echo $e->getMessage();
}
Just a snippet from my framework. Of course you’ll have to change it to your liking, but you should be able to get the general idea there. They key is this part here:
try {
//DB Stuff
} catch(PDOException $e) {
echo $e->getMessage();
}
I Still Don’t See The Error
If you’ve done both of what I’ve listed here and still have trouble, your problem has nothing to do with enabling error reporting. The code provided will show you the error with a Database Connection itself, and inside of PHP code. You must have a completely different issue if this has not shown you an error you’re chasing.
You’ll likely need to be a bit more descriptive on exactly what you’re chasing, and what you’re expecting to see.
When accessing some PHP scripts on my website, I’m getting the dreaded 500 error message. I’d like to know what’s wrong to fix it, but Nginx isn’t logging any PHP errors in the log file I have specified. This is my server block:
server {
listen 80;
server_name localhost;
access_log /home/whitey/sites/localhost/logs/access.log;
error_log /home/whitey/sites/localhost/logs/error.log error;
root /home/whitey/sites/localhost/htdocs;
index index.html index.php /index.php;
location / {
}
location ~ .php$ {
fastcgi_pass unix:/tmp/phpfpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
location ~* .(?:ico|css|js|gif|jpe?g|png)$ {
expires max;
}
}
Note that some PHP scripts work fine, and others don’t. So there isn’t a global problem with PHP, there’s just something in these scripts that’s causing Nginx to throw the 500 error.
How can I get to the bottom of this? The only thing in error.log
is an error about favicon.ico not being found.
asked Aug 13, 2012 at 18:30
4
You have to add the following to your php-fpm pool configurations:
catch_workers_output = 1
You have to add this line to each defined pool!
answered Aug 20, 2012 at 23:21
FleshgrinderFleshgrinder
3,7082 gold badges16 silver badges20 bronze badges
1
I had a similar issue.
I tried deploy phpMyAdmin with php-fpm 7.0 and nginx on CentOS7. Nginx showed me 500.html but there was not errors in any log file.
I did all of this
catch_workers_output = 1
and
display_errors = On
Either nginx log or php-fpm log did not contained any error string.
And when I commented this line in nginx.conf I was able to see in browser page things that was wrong.
# error_page 500 502 503 504 /50x.html;
# location = /50x.html {
# }
That was what helped me understand troubles.
answered Jul 13, 2017 at 12:20
venoelvenoel
1837 bronze badges
php-fpm
throws everything in /var/log/php5-fpm.log
or similar.
answered Aug 13, 2012 at 18:37
erickzettaerickzetta
5892 silver badges4 bronze badges
6
Look in your nginx.conf for an error_log
definition. Maybe nginx writes something in this error log.
You might also enable logging to file on PHP.
answered Aug 13, 2012 at 18:36
1
For me, this seemed to be a problem with upstart, which was routing the logs for php-fpm to it’s own custom location, e.g.:
/var/log/upstart/php5-fpm.log
There’s also some bugginess with ubuntu Precise, 12.04 that may contribute to the lack of logging ability: https://bugs.php.net/bug.php?id=61045 If you’re still running that version.
answered Jul 21, 2015 at 16:55
KzqaiKzqai
1,2784 gold badges18 silver badges32 bronze badges
When PHP display_errors are disabled, PHP errors can return Nginx 500 error.
You should take a look to your php-fpm logs, i’m sure you’ll find the error there. With CentOS 7 :
tail -f /var/log/php-fpm/www-error.log
You can also show PHP errors. In your php.ini, change :
display_errors = Off
to :
display_errors = On
Hope it helps.
answered Jan 22, 2016 at 0:34
This is what happened to me:
When I deleted my error log, nginx noticed that it was no longer missing. When I recreated this file nginx would no longer recognise that it existed, therefore not writing to the file.
To fix this, run these commands (I’m on Ubuntu 14.04 LTS):
sudo service nginx reload
If that doesn’t work, then try:
sudo service nginx restart
answered Aug 12, 2015 at 7:22
dspacejsdspacejs
1111 silver badge3 bronze badges
4
Блог / Программирование / Настроить Nginx для вывода php ошибок в браузер (а не только в log)
Это не является настройкой nginx, а управляется из конфигурации php-fpm.
Настройте в файле php-fpm.conf (к примеру для 7.4 это /etc/php/7.4/fpm/php-fpm.conf):
php_flag[display_errors] = on php_flag[display_startup_errors] = on |
Написать комментарий
Данная запись опубликована в 07.04.2022 15:30 и размещена в Программирование.
Вы можете перейти в конец страницы и оставить ваш комментарий.
Мало букафф? Читайте есчо !
Изменить текст no-results во views программно
Февраль 5, 2020 г.
Drupal views позволяют сконфигурировать сообщение на случай если результат запроса пуст и нельзя срендерить какой либо контент для данного представления.
Данная опция находится во вкладке ‘advanced’ вашего представления. Но в данной статье я покажу …
Читать
The behaviour of these functions is affected by settings in php.ini.
Errors and Logging Configuration Options
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 | |
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_STRICT
andE_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_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
). -
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_WARNING
in 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 valuesyslog
is 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 withx
.-
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
raw
filter 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 ¶
13 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 ¶
3 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.
In my case Zend errors and NGinX — php5 fpm, work like this:
Only I put in public/index.php
error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', 1);
Without If(){...}
But If only to put above code, display error, will give this:
Parse error: syntax error, unexpected '}', expecting ',' or ';' in /usr/local/nginx/html/ZendSkeletonApplication/module/Album/src/Album/Controller/AlbumController.php on line 12
Another thing! Set up this code:
'display_not_found_reason' => true,
'display_exceptions' => true,
in module.config.php like this:
'view_manager' => array(
'template_path_stack' => array(
'album' => __DIR__ . '/../view',
'display_not_found_reason' => true,
'display_exceptions' => true,
),
),
I get all errors of an error.log on screen:
Fatal error: Uncaught exception 'ZendViewExceptionInvalidArgumentException' with message 'Invalid path provided; must be a string, received boolean' in /usr/local/nginx/html/ZendSkeletonApplication/vendor/zendframework/zendframework/library/Zend/View/Resolver/TemplatePathStack.php:201 Stack trace: #0 /usr/local/nginx/html/ZendSkeletonApplication/vendor/zendframework/zendframework/library/Zend/View/Resolver/TemplatePathStack.php(149): ZendViewResolverTemplatePathStack->addPath(true) #1 /usr/local/nginx/html/ZendSkeletonApplication/vendor/zendframework/zendframework/library/Zend/Mvc/Service/ViewTemplatePathStackFactory.php(38): ZendViewResolverTemplatePathStack->addPaths(Array) #2 [internal function]: ZendMvcServiceViewTemplatePathStackFactory->createService(Object(ZendServiceManagerServiceManager), 'viewtemplatepat...', 'ViewTemplatePat...') #3 /usr/local/nginx/html/ZendSkeletonApplication/vendor/zendframework/zendframework/library/Zend/ServiceManager/ServiceManager.php(939): call_user_func(Array, Object(Zend in /usr/local/nginx/html/ZendSkeletonApplication/vendor/zendframework/zendframework/library/Zend/ServiceManager/ServiceManager.php on line 946
I didn’t touch config file as php-fpm in system (Ubuntu 14.04).
In my case Zend errors and NGinX — php5 fpm, work like this:
Only I put in public/index.php
error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', 1);
Without If(){...}
But If only to put above code, display error, will give this:
Parse error: syntax error, unexpected '}', expecting ',' or ';' in /usr/local/nginx/html/ZendSkeletonApplication/module/Album/src/Album/Controller/AlbumController.php on line 12
Another thing! Set up this code:
'display_not_found_reason' => true,
'display_exceptions' => true,
in module.config.php like this:
'view_manager' => array(
'template_path_stack' => array(
'album' => __DIR__ . '/../view',
'display_not_found_reason' => true,
'display_exceptions' => true,
),
),
I get all errors of an error.log on screen:
Fatal error: Uncaught exception 'ZendViewExceptionInvalidArgumentException' with message 'Invalid path provided; must be a string, received boolean' in /usr/local/nginx/html/ZendSkeletonApplication/vendor/zendframework/zendframework/library/Zend/View/Resolver/TemplatePathStack.php:201 Stack trace: #0 /usr/local/nginx/html/ZendSkeletonApplication/vendor/zendframework/zendframework/library/Zend/View/Resolver/TemplatePathStack.php(149): ZendViewResolverTemplatePathStack->addPath(true) #1 /usr/local/nginx/html/ZendSkeletonApplication/vendor/zendframework/zendframework/library/Zend/Mvc/Service/ViewTemplatePathStackFactory.php(38): ZendViewResolverTemplatePathStack->addPaths(Array) #2 [internal function]: ZendMvcServiceViewTemplatePathStackFactory->createService(Object(ZendServiceManagerServiceManager), 'viewtemplatepat...', 'ViewTemplatePat...') #3 /usr/local/nginx/html/ZendSkeletonApplication/vendor/zendframework/zendframework/library/Zend/ServiceManager/ServiceManager.php(939): call_user_func(Array, Object(Zend in /usr/local/nginx/html/ZendSkeletonApplication/vendor/zendframework/zendframework/library/Zend/ServiceManager/ServiceManager.php on line 946
I didn’t touch config file as php-fpm in system (Ubuntu 14.04).
Хостинг-провайдеры нередко отключают или блокируют вывод всех ошибок и предупреждений. Такие ограничения вводятся не просто так. Дело в том, что на рабочих серверах крайне не рекомендуется держать ошибки в открытом доступе. Информация о неисправностях может стать «наживкой» для злоумышленников.
При этом в процессе разработки сайтов и скриптов, очень важно отслеживать возникающие предупреждения. Знать о сбоях и неисправностях также важно и системным администраторам — это позволяет предотвратить проблемы на сайте или сервере.
Самый оптимальный вариант — не просто скрыть показ ошибок, но и настроить запись о них в логах. Это позволит отслеживать предупреждения и не подвергать сервер угрозе.
В статье мы расскажем, как включить и отключить через .htaccess вывод ошибок php, а также двумя другими способами — через скрипт PHP и через файл php.ini.
Обратите внимание: в некоторых случаях изменение настроек вывода возможно только через обращение в техническую поддержку хостинга.
Через .htaccess
Перейдите в каталог сайта и откройте файл .htaccess.
Вариант 1. Чтобы включить вывод, добавьте следующие строки:
php_flag display_startup_errors on
php_flag display_errors on
php_flag html_errors on
Чтобы отключить ошибки PHP htaccess, введите команду:
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
Также выключить .htaccess display errors можно командой:
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_value docref_root 0
php_value docref_ext 0
Если вам нужно проверить или выключить ошибки только в определенных файлах, это можно сделать с помощью вызова PHP-функций.
Вариант 1. Чтобы включить вывод, используйте команду error_reporting. В зависимости от типа ошибок, которые вы хотите увидеть, подставьте нужное значение. Например, команда для вывода всех ошибок будет выглядеть так:
А для всех типов, исключая тип Notice, так:
error_reporting(E_ALL & ~E_NOTICE)
Чтобы отключить вывод, введите команду:
Чтобы отключить логирование повторяющихся ошибок, введите:
# disable repeated error logging
php_flag ignore_repeated_errors on
php_flag ignore_repeated_source on
Вариант 2. Чтобы проверить конкретный кусок кода, подойдет команда ниже. В зависимости от типа ошибок, которые вы хотите увидеть, в скобках подставьте нужное значение. Например, команда для вывода всех ошибок будет выглядеть так:
ini_set('display_errors', 'On')
error_reporting(E_ALL)
После этого в консоли введите:
ini_set('display_errors', 'Off')
Вариант 3. Ещё один из вариантов подключения через скрипт:
php_flag display_startup_errors on
php_flag display_errors on
Для отключения укажите:
php_flag display_startup_errors off
php_flag display_errors off
Вариант 4. Чтобы настроить вывод с логированием через конфигурацию веб-сервера, введите:
- для Apache —
ErrorLog «/var/log/apache2/my-website-error.log»
, - для Nginx —
error_log /var/log/nginx/my-website-error.log
.
Подробнее о других аргументах читайте в документации на официальном сайте php.net.
Через файл php.ini
Настроить отслеживание также можно через файл php.ini. Этот вариант подойдет, когда отображение или скрытие ошибок нужно настроить для всего сайта или кода. Обратите внимание: возможность настройки через файл php.ini есть не у всех, поскольку некоторые хостинг-провайдеры частично или полностью закрывают доступ к файлу.
Вариант 1. Если у вас есть доступ, включить вывод можно командой:
После этого нужно перезагрузить сервер:
sudo apachectl -k graceful
Вариант 2. Чтобы включить вывод, используйте команду error_reporting. В зависимости от типа ошибок, которые вы хотите увидеть, после знака = подставьте нужное значение. Например, команда для вывода всех ошибок будет выглядеть так:
error_reporting = E_ALL
display_errors On
После ввода перезагрузите сервер:
sudo apachectl -k graceful
Чтобы скрыть отображение, во второй строке команды укажите Оff вместо On:
Теперь вы знаете, как настроить не только через PHP и php.ini, но и через htaccess отображение ошибок.
В этом руководстве мы расскажем о различных способах того, как в PHP включить вывод ошибок. Мы также обсудим, как записывать ошибки в журнал (лог).
Как быстро показать все ошибки PHP
Самый быстрый способ отобразить все ошибки и предупреждения php — добавить эти строки в файл PHP:
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
Что именно делают эти строки?
Функция ini_set попытается переопределить конфигурацию, найденную в вашем ini-файле PHP.
Display_errors и display_startup_errors — это только две из доступных директив. Директива display_errors определяет, будут ли ошибки отображаться для пользователя. Обычно директива dispay_errors не должна использоваться для “боевого” режима работы сайта, а должна использоваться только для разработки.
display_startup_errors — это отдельная директива, потому что display_errors не обрабатывает ошибки, которые будут встречаться во время запуска PHP. Список директив, которые могут быть переопределены функцией ini_set, находится в официальной документации .
К сожалению, эти две директивы не смогут отображать синтаксические ошибки, такие как пропущенные точки с запятой или отсутствующие фигурные скобки.
Отображение ошибок PHP через настройки в php.ini
Если ошибки в браузере по-прежнему не отображаются, то добавьте директиву:
display_errors = on
Директиву display_errors следует добавить в ini-файл PHP. Она отобразит все ошибки, включая синтаксические ошибки, которые невозможно отобразить, просто вызвав функцию ini_set в коде PHP.
Актуальный INI-файл можно найти в выводе функции phpinfo (). Он помечен как “загруженный файл конфигурации” (“loaded configuration file”).
Отображать ошибки PHP через настройки в .htaccess
Включить или выключить отображение ошибок можно и с помощью файла .htaccess, расположенного в каталоге сайта.
php_flag display_startup_errors on
php_flag display_errors on
.htaccess также имеет директивы для display_startup_errors и display_errors.
Вы можете настроить display_errors в .htaccess или в вашем файле PHP.ini. Однако многие хостинг-провайдеры не разрешают вам изменять ваш файл PHP.ini для включения display_errors.
В файле .htaccess также можно включить настраиваемый журнал ошибок, если папка журнала или файл журнала доступны для записи. Файл журнала может быть относительным путем к месту расположения .htaccess или абсолютным путем, например /var/www/html/website/public/logs
.
php_value error_log logs/all_errors.log
Включить подробные предупреждения и уведомления
Иногда предупреждения приводят к некоторым фатальным ошибкам в определенных условиях. Скрыть ошибки, но отображать только предупреждающие (warning) сообщения можно вот так:
error_reporting(E_WARNING);
Для отображения предупреждений и уведомлений укажите «E_WARNING | E_NOTICE».
Также можно указать E_ERROR, E_WARNING, E_PARSE и E_NOTICE в качестве аргументов. Чтобы сообщить обо всех ошибках, кроме уведомлений, укажите «E_ALL & ~ E_NOTICE», где E_ALL обозначает все возможные параметры функции error_reporting.
Более подробно о функции error_reporting ()
Функция сообщения об ошибках — это встроенная функция PHP, которая позволяет разработчикам контролировать, какие ошибки будут отображаться. Помните, что в PHP ini есть директива error_reporting, которая будет задана этой функцией во время выполнения.
error_reporting(0);
Для удаления всех ошибок, предупреждений, сообщений и уведомлений передайте в функцию error_reporting ноль. Можно сразу отключить сообщения отчетов в ini-файле PHP или в .htaccess:
error_reporting(E_NOTICE);
PHP позволяет использовать переменные, даже если они не объявлены. Это не стандартная практика, поскольку необъявленные переменные будут вызывать проблемы для приложения, если они используются в циклах и условиях.
Иногда это также происходит потому, что объявленная переменная имеет другое написание, чем переменная, используемая для условий или циклов. Когда E_NOTICE передается в функцию error_reporting, эти необъявленные переменные будут отображаться.
error_reporting(E_ALL & ~E_NOTICE);
Функция сообщения об ошибках позволяет вам фильтровать, какие ошибки могут отображаться. Символ «~» означает «нет», поэтому параметр ~ E_NOTICE означает не показывать уведомления. Обратите внимание на символы «&» и «|» между возможными параметрами. Символ «&» означает «верно для всех», в то время как символ «|» представляет любой из них, если он истинен. Эти два символа имеют одинаковое значение в условиях PHP OR и AND.
error_reporting(E_ALL);
error_reporting(-1);
ini_set('error_reporting', E_ALL);
Эти три строки кода делают одно и то же, они будут отображать все ошибки PHP. Error_reporting(E_ALL) наиболее широко используется разработчиками для отображения ошибок, потому что он более читабелен и понятен.
Включить ошибки php в файл с помощью функции error_log ()
У сайта на хостинге сообщения об ошибках не должны показываться конечным пользователям, но эта информация все равно должна быть записана в журнал (лог).
Простой способ использовать файлы журналов — использовать функцию error_log, которая принимает четыре параметра. Единственный обязательный параметр — это первый параметр, который содержит подробную информацию об ошибке или о том, что нужно регистрировать. Тип, назначение и заголовок являются необязательными параметрами.
error_log("There is something wrong!", 0);
Параметр type, если он не определен, будет по умолчанию равен 0, что означает, что эта информация журнала будет добавлена к любому файлу журнала, определенному на веб-сервере.
error_log("Email this error to someone!", 1, "someone@mydomain.com");
Параметр 1 отправит журнал ошибок на почтовый ящик, указанный в третьем параметре. Чтобы эта функция работала, PHP ini должен иметь правильную конфигурацию SMTP, чтобы иметь возможность отправлять электронные письма. Эти SMTP-директивы ini включают хост, тип шифрования, имя пользователя, пароль и порт. Этот вид отчетов рекомендуется использовать для самых критичных ошибок.
error_log("Write this error down to a file!", 3, "logs/my-errors.log");
Для записи сообщений в отдельный файл необходимо использовать тип 3. Третий параметр будет служить местоположением файла журнала и должен быть доступен для записи веб-сервером. Расположение файла журнала может быть относительным путем к тому, где этот код вызывается, или абсолютным путем.
Журнал ошибок PHP через конфигурацию веб-сервера
Лучший способ регистрировать ошибки — это определить их в файле конфигурации веб-сервера.
Однако в этом случае вам нужно попросить администратора сервера добавить следующие строки в конфигурацию.
Пример для Apache:
ErrorLog "/var/log/apache2/my-website-error.log"
В nginx директива называется error_log.
error_log /var/log/nginx/my-website-error.log;
Теперь вы знаете, как в PHP включить отображение ошибок. Надеемся, что эта информация была вам полезна.
- Печать
Страницы: [1] Вниз
Тема: Nginx + php5-fpm вывод ошибки. (Прочитано 10665 раз)
0 Пользователей и 1 Гость просматривают эту тему.
rootoot
Собрал Nginx с модулями, все работает (модули, Nginx), решил поставить PHP.
apt-get update
Всё вроде встало, в что прописать в Nginx конфиг ? Прописал вот это.
apt-get install php5-fpm
location ~ .php$ {
Но выводит ошибку.
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /user/local/nginx/fastcgi_temp;
}
nginx: [emerg] open() «/user/local/nginx/fastcgi_temp» failed (2: No such file or directory) in /usr/local/nginx/conf/nginx.conf:56
Ругается на это
include /user/local/nginx/fastcgi_temp;
.ubuntufan
Наверное, подразумевалось include fastcgi_params; ?
rootoot
Да и парамс тоже не работает.
Прописал вот такое.
location ~ .php$ {
#error_log = /var/log/nginx/php5-fpm.log
fastcgi_pass unix:/var/run/php5-fpm.socks;
fastcgi_index index.php;
fastcgi_intercept_errors on; # только на период тестирования
# Включаем параметры из /etc/nginx/fastcgi_param
include fastcgi_params;
# Путь к скрипту, который будет передан в php-fpm
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_ignore_client_abort off;
}
Пишет смотрите логи свои.
2015/03/11 16:10:52 [crit] 6376#0: *28 connect() to unix:/var/run/php5-fpm.socks failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.socks:", host: "127.0.0.1"
Как проверить или узнать куда установился PHP ? Так как к эту файлу идёт обращение, он есть, но пустой 0кб.
2015/03/11 16:11:07 [crit] 6376#0: *28 connect() to unix:/var/run/php5-fpm.socks failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.socks:", host: "127.0.0.1
.ubuntufan
Наверное, подразумевалось fastcgi_pass unix:/var/run/php5-fpm.sock; ?
rootoot
Нет, всё также в логах.
file /etc/php5/fpm/php-fpm.conf
Может где то тут ? Как вообще узнать полный путь ?
.ubuntufan
Нет, всё также в логах.
В логах у тебя .socks.
cat /etc/php5/fpm/pool.d/www.conf | grep "listen ="
rootoot
2015/03/11 16:28:28 [crit] 6807#0: *1 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "127.0.0.1"
Пользователь решил продолжить мысль [time]11 Март 2015, 17:42:10[/time]:
live@live-P5KC:~$ cat /etc/php5/fpm/pool.d/www.conf | grep "listen ="
listen = /var/run/php5-fpm.sock
Пользователь решил продолжить мысль 11 Марта 2015, 16:44:41:
Полностью конфиг может там что не так.
#user nobody;
worker_processes 6;
events {
worker_connections 1024;
}
rtmp_auto_push on;
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name localhost;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
location / {
root /var/www;
index index.html index.htm index.php;
}
# rtmp control
location /control {
rtmp_control all;
}
error_page 500 502 503 504 /50x.html;
location =/50x.html
{
root html;
}
location ~ .php$ {
#error_log = /var/log/nginx/php5-fpm.log
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_intercept_errors on; # только на период тестирования
# Включаем параметры из /etc/nginx/fastcgi_param
include fastcgi_params;
# Путь к скрипту, который будет передан в php-fpm
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_ignore_client_abort off;
}
}
}
« Последнее редактирование: 11 Марта 2015, 16:44:41 от rootoot »
.ubuntufan
всё также в логах.
connect() to unix:/var/run/php5-fpm.socks failed (2: No such file or directory
connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied)
Так же?
Укажи в конфиге nginx пользователя:
user www-data;
Вместо
#user nobody;
rootoot
Каюсь моя не внимательность, но сейчас пишет нет файла. «File not found.»
Html запускает, а PHP нет.
015/03/11 16:54:25 [error] 7313#0: *34 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "127.0.0.1"
.ubuntufan
Укажи с помощью директивы root путь, где у тебя PHP файлы находтся:
...
server {
listen 80;
server_name localhost;
root /var/www;
...
rootoot
Ну что я могу сказать, ОГРОМНОЕ СПАСИБО !!!!
Всё заработало !!! Проверил infophp(); всё сработало как нужно !
- Печать
Страницы: [1] Вверх