I've since determined that current behavior *partially* supports
error_log, but not the way you'd think it should.
In the main part of php-fpm.conf, error_log = syslog works as you'd
expect, at least in php 5.3.10, which I've now installed. But the only
data that goes to syslog() will be information about php-fpm itself --
really just start/stop messages. What PHP itself does will not be
captured. This current behavior is not particularly valuable.
But in a pool definition block,
php_admin_value('error_log') = syslog
will interpret "syslog" as a partial file system path (on my build of
php-fpm, the file "/usr/syslog"), and not as the "magic" keyword
syslog. This is, in my opinion, a bug.
I'm working around this by using the "infile" module in rsyslog, which
will make it possible for me to have rsyslog follow an error log file.
But we'll see how reliable that set up turns up to be, especially once I
work in log rolling.
Anybody know a better way to do this?
Thanks,
Rob
On 06/13/2012 06:25 PM, Rob Thorne wrote:
> I'm currently using 5.3.6-13ubuntu3.7, php5-fpm, with nginx
> 1.0.5-1ubuntu0.1, and am having no luck at all pushing errors to
> syslog (actually, rsyslog on Ubuntu).
>
> Is there _any_ configuration where this will work right now? I can
> get errors to go to an error file by putting
>
> error_log = /path/to/file/error.log
>
> into a pool definition file. But if I do
>
> error_log = syslog
>
> as far as I can tell, the bits just go to /dev/null. At the very
> least, I cannot figure out a combination of syslog ident and facility
> that will receive these messages. It certainly is not appearing in
> /var/log/syslog.
>
> If this works, what do I need to do with syslog to see the output from
> error_log() (or calls to error handlers, for that matter, for php
> errors). If it doesn't work, how can I work around this limitation
> of php-fpm?
>
> Thanks,
> Rob
>
