Language File Not Loading, Fails to Translate Defines

[cachehit]

I don't know for an absolute fact at what layer - the OS (SPARC Solaris 8), apache (1.3.39),. php (4.4.8), zen-cart (1.3.7), or somewhere in between - that this bug resides, so my apologies if I've posted in the wrong forum. I do know that the Solaris machine where this bug crops up is hosting many dozens of websites from the same apache config and, even as the zen-cart misbehavior begins, every other site, even every other PHP site and the few other sites using mod_frontpage or mod_perl, all function fine. As I said, even Zen-cart continues working except it seems to have forgotten how to interpret the define()'s (or it can't find them..).

I have php configured to log to a file, at this time actually with error_report set tp E_ALL because I'm so perplexed by this whole thing. Regardless it doesn't log any errors when this behavior begins. Likewise apache logs no errors.

I'm still very curious if anyone has seen anything similar at all to this behavior.

thanks,
--
John

[DrByte]

In regards to server setup:

SUN OS (Solaris)
MySQL 4.0.26
Apache/1.3.37
PHP 4.4.7 (Zend: 1.3.0)

the OS (SPARC Solaris 8), apache (1.3.39),. php (4.4.8), zen-cart (1.3.7)

The only common thread I see there is Solaris. Unfortunately I don't have the budget to purchase and configure such a machine here for testing, let alone the resources to diagnose possible issues in using it as a webserver platform.

I suppose the ideal troubleshooting approach would be to get PHP to log every attempt at doing a "require" or "include" operation, along with its success or failure, and of course which session ID the request was occurring in.

But, since you've indicated that there have been no PHP errors logged when these problems happen, I suspect it's not a PHP-specific problem, and is actually happening at a higher level ... which technically means it wouldn't be a Zen Cart problem specifically. But, lest I sound like I'm pointing fingers and you get all defensive, I offer the following suggestions:

- check the amount of RAM configured for PHP instances.

- check the number of file handles that PHP (or actually Apache, since PHP is likely running as an apache module and therefore Apache is the owner of the PHP processes) is limited to using at a given time. How does that compare against Filesystem limits/settings? or disk quotas? Does raising that limit make any difference?

- what happens if you change PHP to not be an Apache module, and instead run as a CGI application? (NOTE: I normally do NOT recommend that approach, as it usually creates a number of headaches and should not be done unless you have a good reason for doing it and know how to properly configure system permissions etc) .... you might try this during off-hours, since it will likely break most sites running PHP on your server until everyone changes permissions levels. Read up on the apache and/or php websites or maybe a site like webhostingtalk.com about configuring your server that way.

- what is the server load at the time when it happens?

- is there any way to narrow down the symptoms of all other factors that may be occurring at the time of failure? number of connections, number of open files, amount of ram allocated to various processes, maybe each process, whether any other PHP-based sites are affected by it, is there anything in .htaccess rules causing increased server load, etc etc.