PHP CLI 不会记录错误
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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
请检查运行 PHP CLI 的用户帐户是否具有对
/var/log/php_errors.log
的写入权限。此外,您可以验证您是否使用正确的 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:
在 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
文件:由于有问题的服务器由从事各种项目的 Web 开发人员使用,我为他们建立了一个名为
www- 的通用组用户。在这种情况下,我希望
php_errors.log
能够被www-users
读取和写入,我像这样更改文件的所有权:然后更改文件如下:
是的,从安全角度来看,让
www-users
中的任何人都可以读取和写入日志文件并不是很好。但这是一个受控的共享工作环境。所以我相信用户会尊重这样的事情。此外,当 PHP 从 CLI 运行时,任何可以执行此操作的用户都需要对日志进行写访问才能写入日志。接下来,进入
/etc/php5/cli/php.ini
调整默认的 Ubuntu 12.04 设置以匹配这个新的日志文件:令人高兴的是 Ubuntu 中默认启用
log_errors
12.04:但为了允许记录到文件,我们需要更改
error_log
以匹配新文件,如下所示:设置
logrotate.d
脚本。现在应该是这样了,但由于我不想让日志失去控制,所以我为
php_errors.log
设置了logrotate.d
。在/etc/logrotate.d/
中创建一个名为php-cli
的文件,如下所示:并将此日志旋转守护进程脚本的内容放入其中:
测试设置。
完成后,让我们使用 David Chan 的提示 测试设置:
如果运行正确,您应该会弹回到空命令提示符,因为 PHP CLI 错误不再发送到标准输出。因此,请检查实际的 php_errors.log 中是否有如下所示的测试错误消息:
并且其中应该有一个带时间戳的错误行,如下所示:
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: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 thephp_errors.log
to be readable and writable bywww-users
I change the ownership of the file like this:And then change the permissions of the file to this:
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:Happily
log_errors
is enabled by default in Ubuntu 12.04:But to allow logging to a file we need to change the
error_log
to match the new file like this: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 thephp_errors.log
. Create a file calledphp-cli
in/etc/logrotate.d/
like this:And place the contents of this log rotate daemon script in there:
Testing the setup.
With that done, let’s test the setup using David Chan’s tip:
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:And there should be a timestamped error line in there that looks something like this:
作为诊断,您可以尝试通过以下方式强制写入错误日志:
您现在应该在日志中看到测试 123:
As a diagnostic, you can attempt to force a write to the error log this way:
You should now see test 123 in your log:
PHP 的日志/报告行为也依赖于 error_reporting。
某些 PHP 框架(例如 CodeIgniter)会执行
error_reporting(E_STRICT) 语句或等效语句,在生产模式下,这将严重减少记录的错误的数量/类型。
如果你想调试某些东西,那么你可以将以下语句放在代码之前:
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:
如果您无法弄清楚原因或者可能没有文件 php.ini 的用户权限,调试无信息解析错误的另一种方法是将您的 PHP 源代码包装在另一个 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:
在 PHP 文件中
在终端
输出
你搞砸了!
In the PHP file
In the terminal
Output
You messed up!