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

Fatal error on first pageview after clusterize

    Details

      Description

      In the testsystem we have sometime the problem that the first pageview after running clusterize returns a fatal error:

      Fatal error: eZ Publish did not finish its request
       
      The execution of eZ Publish was abruptly ended. Contact website owner with current url and what you did, and owner will be able to debug the issue further.
      

      (this text seems to origin from index.php)

      Hitting F5 (refresh) on the same page then succeeds without an error. I suspected the problem is related to generation of cache so i played a bit around with removing it in order to try to easier reproduce it.

      Steps to reproduce

      So, here is how to reproduce it more easily.
      Setup:

      install ezp plain package
      clusterize it with ezdfs or ezdb
      take backup of var dir:
       # cp -a var var.01
      

      Then use the following procedure to reproduce the problem:

      Remove cache from tables:
        mysql> delete from ezdbfile where scope != 'content';
      alternative:
        mysql> delete from ezdfsfile where scope != 'content';
      prepare var dir:
        # rm -Rf var; cp -a var.01 var
        (or just make an empty var ) :
        # rm -Rf var; mkdir var; chmod a+rwx var
       
      Access http://mysite.com/plain_site
      (accessing http://mysite.com/plain_site_admin seems to work fine though )
      

        Activity

        Hide
        Vidar Langseid added a comment -

        happens both with ezdb and ezdfs cluster handlers

        Show
        Vidar Langseid added a comment - happens both with ezdb and ezdfs cluster handlers
        Hide
        Vidar Langseid added a comment - - edited

        Same problem stoke us when testing on postgres

        So, investigated this even further and found it even easier (but also weirder) to reproduce.
        The problem seems to be related to the var/log directory.

        If you remove var/cache and var/log (in clustermode you also have to remove cache in db), then accessing plain_site (have only tested with plain, not with ezwebin/flow), you'll get the fatal error
        However, why would someone delete var/log, right? Well, you don't.. Cause with the attached log.tar.gz (extract it in var/), and removing var/cache you'll also get the problem. I have no idea why the particular content of log.tar.gz reproduces the problem. (the content of the log.tar.gz files is just how it is after installing plain on postgres, I havn't done any manuall changes to the content)

        ps: after extracting log.tar.gz you have to fix permissions (seems like tar made the permissions a bit more restrictive during compression:

        $ cd var   <----- ( make sure you don't write "cd /var" )
        $ rm -Rf log
        $ tar -xzf log.tar.gz
        $ chmod a+rwx -R log
        

        So to sum up:
        If cache is generated while var/log is empty (or contain some certain data) we get a crash

        ps :
        With the log.tar.gz file attached, I am also reproduce the crash on mysql. On mysql I also get some additional errors which makes no sence to me (sounds like a ini cache problem):

        Fatal error: eZINI::variable: Undefined group: 'FileSettings' in site.ini in /data1/www/apache2php52/ezp430/.run/lib/ezutils/classes/ezdebug.php on line 583
        Fatal error: eZ Publish did not finish its request
         
        Fatal error: eZINI::variable: Undefined group: 'DebugSettings' in site.ini in /data1/www/apache2php52/ezp430/.run/lib/ezutils/classes/ezdebug.php on line 583
        

        Show
        Vidar Langseid added a comment - - edited Same problem stoke us when testing on postgres So, investigated this even further and found it even easier (but also weirder) to reproduce. The problem seems to be related to the var/log directory. If you remove var/cache and var/log (in clustermode you also have to remove cache in db), then accessing plain_site (have only tested with plain, not with ezwebin/flow), you'll get the fatal error However, why would someone delete var/log, right? Well, you don't.. Cause with the attached log.tar.gz (extract it in var/), and removing var/cache you'll also get the problem. I have no idea why the particular content of log.tar.gz reproduces the problem. (the content of the log.tar.gz files is just how it is after installing plain on postgres, I havn't done any manuall changes to the content) ps: after extracting log.tar.gz you have to fix permissions (seems like tar made the permissions a bit more restrictive during compression: $ cd var <----- ( make sure you don't write "cd /var" ) $ rm -Rf log $ tar -xzf log.tar.gz $ chmod a+rwx -R log So to sum up: If cache is generated while var/log is empty (or contain some certain data) we get a crash ps : With the log.tar.gz file attached, I am also reproduce the crash on mysql. On mysql I also get some additional errors which makes no sence to me (sounds like a ini cache problem): Fatal error: eZINI::variable: Undefined group: 'FileSettings' in site.ini in /data1/www/apache2php52/ezp430/.run/lib/ezutils/classes/ezdebug.php on line 583 Fatal error: eZ Publish did not finish its request   Fatal error: eZINI::variable: Undefined group: 'DebugSettings' in site.ini in /data1/www/apache2php52/ezp430/.run/lib/ezutils/classes/ezdebug.php on line 583
        Hide
        Vidar Langseid added a comment -

        log.tar.gz var/log content to reproduce problem

        Show
        Vidar Langseid added a comment - log.tar.gz var/log content to reproduce problem
        Hide
        Bertrand Dunogier added a comment -

        Fixed in guthub master (4.4.0beta3):
        http://github.com/ezsystems/ezpublish/commit/0c288344b3fcaf109493d9118baa1ab8dc80f071

        The error was caused by the deprecated INI files naming strict warning, that ended up as a PHP E_USER_ERROR due to site.ini not being loaded when some settings were in a .ini.append file.

        Show
        Bertrand Dunogier added a comment - Fixed in guthub master (4.4.0beta3): http://github.com/ezsystems/ezpublish/commit/0c288344b3fcaf109493d9118baa1ab8dc80f071 The error was caused by the deprecated INI files naming strict warning, that ended up as a PHP E_USER_ERROR due to site.ini not being loaded when some settings were in a .ini.append file.
        Hide
        Geir Arne Waaler added a comment -

        The issue is fixed. I move it to Closed.

        Geir Arne Waaler
        eZ Documentation

        Show
        Geir Arne Waaler added a comment - The issue is fixed. I move it to Closed. Geir Arne Waaler eZ Documentation

          People

          • Assignee:
            Bertrand Dunogier
            Reporter:
            Vidar Langseid
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: