[jira] Created: (WSFPHP-399) Axis2 log files created wrong time/wrong user

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[jira] Created: (WSFPHP-399) Axis2 log files created wrong time/wrong user

JIRA jira@wso2.org
Axis2 log files created wrong time/wrong user

                 Key: WSFPHP-399
                 URL: https://wso2.org/jira/browse/WSFPHP-399
             Project: WSO2 WSF/PHP
          Issue Type: Bug
          Components: WSService
    Affects Versions: 2.0.0
         Environment: Linux/Apache/mod_php
            Reporter: Dolf Starreveld
            Priority: Highest

The WSF/PHP framework can keep log files in /tmp/wsf_php_{client,server}.log. These files are actually written by the axis code. When the file exceeds size 32M axis attempts to "rotate" the log file. It does so by copying the current contents to a file of the same name with ".old" appended. Next it reopens the log file with fopen(file, "w+") thus intending to truncate the large file in the process.
Problem is that (at least in my config) when running mod_php the initial log file creation (containing some axis version numbers etc), happens during server startup time before the httpd process has switched users away from "root" to "apache". Consequently the log file is owned by root, but remains writeable to the httpd processes because the inherit the open file handle.... Until the rotate happens and they reopen the file. it fails because a process with effective user id "apache" tries to write to a file owned by "root" and does not have permission.
The result is a null file description, and the current logging line doesn't happen. When the next logging line comes by, the process repeats, copy 32M of data gain, failing to open etc.

If (for example), the copy of 32M takes 0.1 seconds, then attempting to log 300 lines (which isn't hard in TRACE mode) will take upwards of 30 seconds, causing the PHP script to be killed with all due consequences. Of course all logging effectively stops as well.

This makes the code pretty unusable in a production environment. A workaround is to run a cron job to change file ownership to apache and run it frequently enough that the file could not reach 32M in size before it runs at least once.

I have actually observed all the above using gdb tracing through the code. I have also observed that the copy gets made over and over and the changing ownership resolves the situation.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


Wsf-c-dev mailing list
[hidden email]