Edit report at http://bugs.php.net/bug.php?id=52052&edit=1

 ID:                 52052
 Comment by:         kyle_leaders at mcgraw-hill dot com
 Reported by:        ef-lists at email dot de
 Summary:            add syslog support to FPM
 Status:             Assigned
 Type:               Feature/Change Request
 Package:            FPM related
 Operating System:   Linux/*NIX
 PHP Version:        5.3SVN-2010-06-11 (SVN)
 Assigned To:        fat
 Block user comment: N
 Private report:     N

 New Comment:

As a small fix to this, I just noticed that in 5.3.5, PHP-FPM logs
correctly to 

the syslog, but the syslog tag is incorrect.



If for example you have a pool named "www" it will log to syslog like
so:

2011-02-15 13:28:09.172141-05:00 hostname w: PHP Warning:  ocierror()
expects 

parameter 1 to be resource, null given in filename.php on line 177



Similarly if you have a longer pool name (poolname) it'll show up like
so:

2011-02-15 13:28:09.172141-05:00 hostname olname: PHP Warning: 
ocierror() 

expects parameter 1 to be resource, null given in filename.php on line
177



It seems to be chopping off the first 2 characters of the pool name when
it 

reports the syslog tag/program name to syslog.


Previous Comments:
------------------------------------------------------------------------
[2011-02-10 07:58:45] ef-lists at email dot de

Oh you're right. We're actually experiencing this issue here.



At least the master process should always log to the configured
ident/facility - that's configuration and process manager
warnings/errors. By far the most important log output from FPM, IMHO.



I don't think this is a critical issue for FPM, as log output is never
discarded and other sapis (milter, thttpd, mod_php with Apache ErrorLog
set to syslog) do it the same way - although it would be nice to see
this resolved. I still wonder how to properly do this... open a separate
socket and mimic syslog behaviour? How to address this on Windows?



If you have updates, I'd be really curious. If I can help, let me know.
:-)

------------------------------------------------------------------------
[2011-01-29 15:46:44] f...@php.net

thx for the up to date patch. But there is still a remaining problem:



php_syslog(), openlog() and closelog() can be called from FPM code, core
code, 

user script, module, sapi, ... 



If two calls to openlog() are made from two different places. Then this
is not 

sure than php_syslog() will log the right ident and facility.



This a global reflection to make around PHP and not only in FPM.



I'm working on it.

------------------------------------------------------------------------
[2011-01-28 15:53:44] ef-lists at email dot de

Hi,



added a new patch, which can be applied to a vanilla PHP 5.3.5.



compiles and runs with:

--enable-debug without relevant warnings

--enable-maintainer-zts

without other flags

with having HAVE_SYSLOG_H in main/php_config.h undefined



changes:

* modified patch to work with FPM in 5.3.5

* added new parameters to config dump (todo: translate syslog prio and
facility to nice human-readable values)

* made comparing syslog facilities case-insensitive

* replaced syslog() calls with php_syslog()



Regards,

Edgar

------------------------------------------------------------------------
[2011-01-12 16:15:58] ef-lists at email dot de

Hi Jerome,



are there any updates on this issue yet? With PHP 5.3.4 and PHP 5.3.5
the latest patch doesn't work anymore.



I'd be willing to port it to the latest release, if you're interested.
I'd still like to see this integrated into trunk and 5.3.X.



Regards,

Edgar

------------------------------------------------------------------------
[2010-07-22 23:37:45] f...@php.net

some answers to your questions:



1- this is a bug. All comparaison should use strcasecmp so that users
can type 

facilities and log level with the case they want.



2- you're right. php_syslog() should be used instead of syslog()



4- after testing and validating, yes of course.



I need to take time reviewing all this. Thx again !

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    http://bugs.php.net/bug.php?id=52052


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1

Reply via email to