PHP CLI 不会记录错误

发布于 2024-11-16 02:25:52 字数 225 浏览 4 评论 0原文

PHP 目前不会记录命令行产生的错误。

我有:

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

在文件 /etc/php5/cli/php.ini 中。

我是否缺少进一步的设置来使其正常工作?

PHP currently will not log errors produced from the command line.

I have:

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

in file /etc/php5/cli/php.ini.

Am I missing a further setting to get this working?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

傾旎 2024-11-23 02:25:52

请检查运行 PHP CLI 的用户帐户是否具有对 /var/log/php_errors.log 的写入权限。

此外,您可以验证您是否使用正确的 php.ini 文件,如下所示:

php -a -c /etc/php5/cli/php.ini

Please check that the user account running PHP CLI has write access to /var/log/php_errors.log.

Additionally, you can verify that you are using the correct php.ini file like this:

php -a -c /etc/php5/cli/php.ini
月光色 2024-11-23 02:25:52

Ubuntu 12.04(Precise Pangolin)环境,所以我想发布一个总结我所学到的答案。除了David Chan提供的重要信息以及作为 George Cummins,我创建了一个 logrotate.d 脚本来确保 PHP CLI 错误日志也不会失控设置此选项后,多个用户将能够将错误记录到常见的 PHP CLI 错误日志中。

首先,PHP CLI 的默认行为是将错误消息记录到标准输出;记录到文件不是默认行为。这通常意味着登录到运行 PHP CLI 命令的同一命令行终端会话。虽然 PHP ini 文件确实有针对指定 error_log 的调整,但需要进行其他调整才能真正使其正常工作。

首先,我必须创建一个初始 php_errors.log 文件:

sudo touch /var/log/php_errors.log

由于有问题的服务器由从事各种项目的 Web 开发人员使用,我为他们建立了一个名为 www- 的通用组用户。在这种情况下,我希望 php_errors.log 能够被 www-users 读取和写入,我像这样更改文件的所有权:

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

然后更改文件如下:

sudo chmod 664 /var/log/php_errors.log

是的,从安全角度来看,让 www-users 中的任何人都可以读取和写入日志文件并不是很好。但这是一个受控的共享工作环境。所以我相信用户会尊重这样的事情。此外,当 PHP 从 CLI 运行时,任何可以执行此操作的用户都需要对日志进行写访问才能写入日志。

接下来,进入 /etc/php5/cli/php.ini 调整默认的 Ubuntu 12.04 设置以匹配这个新的日志文件:

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

令人高兴的是 Ubuntu 中默认启用 log_errors 12.04:

log_errors = On

但为了允许记录到文件,我们需要更改 error_log 以匹配新文件,如下所示:

error_log = /var/log/php_errors.log

设置 logrotate.d 脚本。

现在应该是这样了,但由于我不想让日志失去控制,所以我为 php_errors.log 设置了 logrotate.d。在 /etc/logrotate.d/ 中创建一个名为 php-cli 的文件,如下所示:

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

并将此日志旋转守护进程脚本的内容放入其中:

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

测试设置。

完成后,让我们使用 David Chan 的提示 测试设置:

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

如果运行正确,您应该会弹回到空命令提示符,因为 PHP CLI 错误不再发送到标准输出。因此,请检查实际的 php_errors.log 中是否有如下所示的测试错误消息:

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

并且其中应该有一个带时间戳的错误行,如下所示:

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

This question and answer thread was very helpful to me while setting up PHP CLI logging on an Ubuntu 12.04 (Precise Pangolin) environment, so I wanted to post an answer that distills what I learned. In addition to the great information provided by David Chan as well as George Cummins, I have created a logrotate.d script to ensure the PHP CLI error log doesn’t grow out of control as well as set this up so multiple users will be able to log errors to the common PHP CLI error log.

First, the default behavior of the PHP CLI is to log error messages to standard output; logging to a file is not default behavior. Which usually means logging to the same command line terminal session that is running the PHP CLI command. While the PHP ini file does have accommodations for a specified error_log additional accommodations need to be made to truly make it work.

First, I had to create an initial php_errors.log file:

sudo touch /var/log/php_errors.log

Since the server in question is used by web developers working on various projects, I have set up a common group for them called www-users. And in this case, I want the php_errors.log to be readable and writable by www-users I change the ownership of the file like this:

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

And then change the permissions of the file to this:

sudo chmod 664 /var/log/php_errors.log

Yes, from a security standpoint having a log file readable and writable by anyone in www-users is not so great. But this is a controlled shared work environment. So I trust the users to respect things like this. And besides, when PHP is run from the CLI, any user who can do that will need write access to the logs anyway to even get a log written.

Next, go into /etc/php5/cli/php.ini to adjust the default Ubuntu 12.04 settings to match this new log file:

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

Happily log_errors is enabled by default in Ubuntu 12.04:

log_errors = On

But to allow logging to a file we need to change the error_log to match the new file like this:

error_log = /var/log/php_errors.log

Setup a logrotate.d script.

Now that should be it, but since I don’t want logs to run out of control I set a logrotate.d for the php_errors.log. Create a file called php-cli in /etc/logrotate.d/ like this:

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

And place the contents of this log rotate daemon script in there:

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

Testing the setup.

With that done, let’s test the setup using David Chan’s tip:

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

If that ran correctly, you should just be bounced back to an empty command prompt since PHP CLI errors are no longer being sent to standard output. So check the actual php_errors.log for the test error message like this:

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

And there should be a timestamped error line in there that looks something like this:

[23-Jul-2014 16:04:56 UTC] This is an error test that we hope works.
冷情 2024-11-23 02:25:52

作为诊断,您可以尝试通过以下方式强制写入错误日志:

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

您现在应该在日志中看到测试 123:

tail /var/log/php_errors.log

As a diagnostic, you can attempt to force a write to the error log this way:

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

You should now see test 123 in your log:

tail /var/log/php_errors.log
許願樹丅啲祈禱 2024-11-23 02:25:52

PHP 的日志/报告行为也依赖于 error_reporting。

某些 PHP 框架(例如 CodeIgniter)会执行 error_reporting(E_STRICT) 语句或等效语句,在生产模式下,这将严重减少记录的错误的数量/类型。

如果你想调试某些东西,那么你可以将以下语句放在代码之前:

error_reporting(E_ALL);

The logging/reporting behaviour of PHP is dependent on error_reporting too.

Some PHP frameworks (for example, CodeIgniter) execute an error_reporting(E_STRICT) statement or equivalent, when in production mode, which will severely reduce the number/kind of logged errors.

If you want to debug something, then you can just put the following statement right before your code:

error_reporting(E_ALL);
江城子 2024-11-23 02:25:52

如果您无法弄清楚原因或者可能没有文件 php.ini 的用户权限,调试无信息解析错误的另一种方法是将您的 PHP 源代码包装在另一个 PHP 源代码中文件的主体类似于:

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

include "mybustedfile.php";

If you can't figure out what why or perhaps don't have user permissions on file php.ini, another way to debug a no-information parse error is to wrap your PHP source in another PHP source file with a body something like:

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

include "mybustedfile.php";
埋葬我深情 2024-11-23 02:25:52

在 PHP 文件中

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

在终端

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

输出

你搞砸了!

In the PHP file

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

In the terminal

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

Output

You messed up!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文