CommunityPlus+ logging behaviour depends on if a site has a site-specific configuration or not. If a site-specific configuration is used via siteadd (the
-I flag), then the logs will go into
/www/site_name_here/logs/php_error.log. If using not using a site-specific configuration (or if using CLI), then it goes to to
/QOpenSys/var/log/php_error.log. We recommend using site-specific configuration (and thus logs), as it requires less setup.
If you want to change this, edit (for site-specific)
/www/site_name_here/phpconf/php.ini or (for global)
/QOpenSys/etc/php/php.ini and change the value of
error_log. PHP will write warnings, notices, and errors to the chosen location if permissions are set properly.
- For site-specific configurations, the permissions on the log file are set automatically. However, for global configuration, to ensure that PHP can write to the error log, be sure to grant appropriate permissions to the PHP user (usually
QTMHHTTPfor the web). If the user running PHP doesn’t have permissions to write to the file,
error_logwill be ignored. To let PHP create and write to the error log, set the following permissions for the PHP user:
- At least *W on the log file (
/QOpenSys/var/log/php_error.logby default) if it exists
- At least *WX on the parent directory (
- At least *X on all directories above the parent directory (
/QOpenSys/var/and up, by default–which should be already set).
- At least *W on the log file (
- After changing the value of
error_logor any other values in php.ini, you’ll need to restart your web server for changes to take effect on your web site.
- When you’ve finished, PHP can write timestamped error messages in your own PHP error log file.
- error_log PHP manual page
If error_log isn’t set: for web sites, the FastCGI handler will let errors bubble up to the web server, generally causing error messages to end up in the website’s standard Apache error log.
Large log files are hard to work with. If your log file grows large, we recommend renaming it so that PHP will create an empty log file. This practice is called “Log Rotation.” Apache logs can be rotated using the
LogMaint direcive, but what about PHP error logs?
The simplest way to rotate PHP error logs is with a CL program that renames your old log using a timestamp. Schedule the CL program to run weekly or so. We adapted a CL program provided by Zend’s Rod Flohr to work well for CommunityPlus+ PHP (you can call it PHPLOGRTT):
PGM DCL VAR(&TIMESTAMP) TYPE(*CHAR) LEN(20) DCL VAR(&NEWNAME) TYPE(*CHAR) LEN(30) RTVSYSVAL SYSVAL(QDATETIME) RTNVAR(&TIMESTAMP) CHGVAR VAR(&NEWNAME) VALUE('php_error.log.' *CAT &TIMESTAMP) RNM OBJ('/QOpenSys/var/log/php_error.log') + NEWOBJ(&NEWNAME) ENDPGM
logrotate tool being included in IBM i 7.4 TR3, logrotate may become a preferred approach in the future.
Advanced options and tips
error_log value is used for both web and command line (CLI).
If running PHP from CLI, you can override error_log like so:
php -d error_log=value myscript.php
If you set
error_log to an empty value (i.e.
php -d error_log= myscript.php), errors will be output according to the PHP environment:
- If you run PHP from a command line interactively, you’ll see the errors on your terminal. This can be a great troubleshooting technique.
- If running in batch mode CLI, errors will be written to “standard error” output. You can redirect the standard error to a file with this bit of shell syntax:
php myscript.php 2> error.txt
As with the
-d error_log=... trick, you can have a separate error log for each invocation.
error_log value is set to
syslog, PHP errors will appear in the system operator log.