eZ publish goes down in flames (a.k.a. segmentation fault) when site.ini (resp. any of its overrides) are newer than the current system time. This can actually happen in a production environmentwhen the file has been copied/moved across systems with dissentient clocks. On Unix system the bug can easily be reproduced and verified by manually "futurizing" the file. Any subsequent call to your eZ publish powered site thereafter will fail (given that you have ini caching enabled)

touch -d "`date -d "+1 hours"`" settings/override/site.ini.append.php

Whereas all other ini files will always be read from cache until you clear it manually, site.ini will only be read from cache if the file hasn't been changed since it has been cached the last time. This would just result in unnecessary caching and not a segfault if it wasn't for the following: after caching of the file (eZINI::loadCache()), eZ publish attempts to tell everybody about it by calling eZLog::writeStorageLog() (lib/ezutils/classes/ezini.php:466). The first thing that method does is calling eZINI::instance() (lib/ezfile/classes/ezlog.php:90) in order to get the desired storage path for the log file. The problem should be obvious by now: eZINI::instance() instantiates a new eZINI object thereby calling eZINI::eZINI() which in turn calls eZINI::load() which - surprise - calls eZINI::loadCache(). Kind of a vicious circle..

So to sum it up:
1. site.ini requested
2. comparison of site.ini mtime and site.ini.cache mtime
3. site.ini is newer => current version gets cached
4. cache successful => write info into storage log
5. logging function needs path to logfile => asks for site.ini
And we are back at 1. again.

Until system time reaches the mtime of site.ini, the cache simply CAN'T be as current as site.ini because the cache file is created on the system itself so its mtime is defined by the system time. While it may be that not every PHP implementation segfaults, you certainly end up in an (almost) endless loop.

Possible fixes:

• sync your clocks (pool.ntp.org)
• mtime of newly created cache files are set to mtime of the actual inis
• system detects such discrepancies and "fixes" the parent mtime

Admittedly this is a rather exotic problem but that just makes it more interesting

On another note: shouldn't there already be an appropriate instance of site.ini which could be returned as soon as eZLog::writeStorageLog() calls eZINI::instance()?