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.

Notes:

  • 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 QTMHHTTP for the web). If the user running PHP doesn’t have permissions to write to the file, error_log will 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 (/QOpenSys/var/log/by default)
    • At least *X on all directories above the parent directory (/QOpenSys/var/and up, by default–which should be already set).
  • After changing the value of error_log or 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.

Log rotation

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

With the logrotate tool being included in IBM i 7.4 TR3, logrotate may become a preferred approach in the future.

Advanced options and tips

The 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.

If the error_log value is set to syslog, PHP errors will appear in the system operator log.