Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-15971

log rotation does not happen while one single eZ php script is executing

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Medium Medium
    • Resolution: Obsolete
    • Affects Version/s: 4.0.7, 4.1.4, 4.2.0
    • Fix Version/s: None
    • Component/s: Misc
    • Labels:
      None

      Description

      The fact is that the filesize() call used to determine if logfile is too big and needs rotation is cached by php.
      Simple test: put this in a view or cronjob

      for ($i = 0; $i < 1024; $i++)
          for ($j = 0; $j < 1024; $j++)
              eZDebug::writeDebug( "$i $j" );
      

      and watch your log grow over 3MB...

      The fix involves clearing the stat cache after logging, but to avoid impacting globally the cache stat it should imho be done only on php > 5.3.0:

              $fileExisted = @file_exists( $fileName );
              if ( $fileExisted and
                   filesize( $fileName ) > eZDebug::maxLogSize() )
              {
                  if ( eZDebug::rotateLog( $fileName ) )
                      $fileExisted = false;
              }
              $logFile = @fopen( $fileName, "a" );
              if ( $logFile )
              {
                  $time = strftime( "%b %d %Y %H:%M:%S", strtotime( "now" ) );
                  $ip = eZSys::serverVariable( 'REMOTE_ADDR', true );
                  if ( !$ip )
                      $ip = eZSys::serverVariable( 'HOSTNAME', true );
                  $notice = "[ " . $time . " ] [" . $ip . "] " . $string . "\n";
                  @fwrite( $logFile, $notice );
                  @fclose( $logFile );
                  // new line
                  clearstatcache( false, $fileName );
                  if ( !$fileExisted )
                  {
                      $ini = eZINI::instance();
                      $permissions = octdec( $ini->variable( 'FileSettings', 'LogFilePermissions' ) );
                      @chmod( $fileName, $permissions );
                  }
                  @umask( $oldumask );
              }
      

        Issue Links

          Activity

          Hide
          ezrobot added a comment -

          This issue has been automatically closed due to the lack of activity over a long period of time. It is very likely that it is obsolete, but if you think it is still valid, do not hesitate to reopen it and mention why.

          Show
          ezrobot added a comment - This issue has been automatically closed due to the lack of activity over a long period of time. It is very likely that it is obsolete, but if you think it is still valid, do not hesitate to reopen it and mention why.
          Hide
          Gaetano Giunta (Inactive) added a comment -

          To avid clearing stat cache on every single log write, using a random check (eg only do this once every 10k calls) is recommended

          Show
          Gaetano Giunta (Inactive) added a comment - To avid clearing stat cache on every single log write, using a random check (eg only do this once every 10k calls) is recommended
          Show
          Eduardo Fernandes (Inactive) added a comment - Related to https://jira.ez.no/browse/EZP-14714 https://jira.ez.no/browse/EZP-19836
          Hide
          Paulo Bras (Inactive) added a comment -

          making a statcache only once in a while leads exactly to the issue EZP-19836.

          Show
          Paulo Bras (Inactive) added a comment - making a statcache only once in a while leads exactly to the issue EZP-19836 .
          Hide
          Gaetano Giunta (Inactive) added a comment -

          The problem happens because the log size is not checked correctly within a single script/web page.
          If we check "every once in a while", we have a good chance that the logs do not grow too big, even if we can not insure byte-precision.
          F.e. we could keep a counter as global variable, and clear stat cache every 100 log writes (within a single page), and/or with a 1% chance on every log write.
          If someone wants to keep logs so small that he's not ready to tolerate having 200 extra rows in them, he's clearly having a problem as sysadmin

          Show
          Gaetano Giunta (Inactive) added a comment - The problem happens because the log size is not checked correctly within a single script/web page. If we check "every once in a while", we have a good chance that the logs do not grow too big, even if we can not insure byte-precision. F.e. we could keep a counter as global variable, and clear stat cache every 100 log writes (within a single page), and/or with a 1% chance on every log write. If someone wants to keep logs so small that he's not ready to tolerate having 200 extra rows in them, he's clearly having a problem as sysadmin
          Hide
          Gaetano Giunta (Inactive) added a comment -

          Ok, so another approach could be to allow users to set log rotation to infinite (0 max size).
          Then we avoid all stat() calls and clearstatcache() as well, fort the perf. conscious guys. Who can then use a separate cronjob to rotate logs.

          Show
          Gaetano Giunta (Inactive) added a comment - Ok, so another approach could be to allow users to set log rotation to infinite (0 max size). Then we avoid all stat() calls and clearstatcache() as well, fort the perf. conscious guys. Who can then use a separate cronjob to rotate logs.

            People

            • Assignee:
              unknown
              Reporter:
              Gaetano Giunta
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: