Hi, It seems to be related issue but don't know if that fixed the problem entirely. Issue was
http://issues.ez.no/IssueView.php?Id=17593

Steps to reproduce are the following
1) Do a fresh install of last community build
2) edit settings/override/site.ini.append.php and comment FileSettings/

part
3) edit your public siteaccess and change FileSettings/VarDir to another folder,
For example, i have changed settings/siteaccess/esl/site.ini.append.php and now that part looks like

[FileSettings]
VarDir=var/web

4) do the same with your administration site
5) now clear your caches with php cli provided script.
6) go to your public siteaccess... you won't see styles at all.

I think this is also affecting to some other things, like dfs cluster expiring. This is how i see it.

In index.php we have this lines https://github.com/ezsystems/ezpublish/blob/master/index.php#L338, added for dealing with this specifing problem.

But, this line is just after

eZExtension::activateExtensions( 'access' );

At that moment, siteaccess settings has not been taken in account yet. Code leads you to
https://github.com/ezsystems/ezpublish/blob/master/lib/ezutils/classes/ezextension.php#L114

$expiryHandler = eZExpiryHandler::instance();

now you can go to eZExpiryHandler class, and see instance function. I
https://github.com/ezsystems/ezpublish/blob/master/lib/ezutils/classes/ezexpiryhandler.php#L128

It checks $GLOBALS['eZExpiryHandlerInstance']. If present, it returns. first time, it calls constructor of this class.
https://github.com/ezsystems/ezpublish/blob/master/lib/ezutils/classes/ezexpiryhandler.php#L20

Well, if you do a log for getting eZSys::cacheDirectory at that time, you will see that result for that is "var/cache" instead of "var/web/cache". And i think because of that, no styles are present, because even /var/cache/expiry.php is modified, /var/web/cache/expiry.php is not, and is not created if you have followed my steps...

This also have lead me to some problem with eZDFS clustering having file.ini.append.php only in my siteaccess.

As said, eZExpiryHandler::instance checks for globals. if related global is not present it calls to the constructor.
well, first time it's called, that's it, when eZExtension::activateExtensions( 'access' ) is called, [ClusteringSettings]/FileHandler returns "eZFSFileHandler", and this is the fileHandler saved in $GLOBALS. so, it always try to work with var/cache/expiry.php locally instead of doing the stuff on the nfs and database...

I know this is a long post and probably i have not explained it very well. but, please can anybody try it and say if i'm saying something wrong?

To be brief, imho it's ok to use eZINI::resetAllInstances( false ), but the problem (i think) occurs because it's called after extension activation function, and that funciton is the one saving expiryHandler globally...

Steps to reproduce

they are in summary