[RESOLVED] Recent appearance of error_log in ALL subdirs: "Module 'timezonedb' already loaded"

Joseph_Sliker

Hi; I have just recently noticed that the error_log files in ALL active subdirectories of my site are adding a new line every single, freakin' time a .php page is called!

Each line reads like so (with the correct time/date):

[16-May-2013 14:13:12 America/Los_Angeles] PHP Warning: Module 'timezonedb' already loaded in Unknown on line 0

...I have been working on a bunch of new stuff, but this is even happening in old parts of the site that have not been touched.

I contacted the host provider support board and was advised to add the following line to my .htaccess file

date.timezone = America/Chicago

(I don't think I have ever edited in 5+ years of using this host)

I added that line...which completely disabled my site. So I found that the apparent correct syntax is actually:

SetEnv TZ America/Chicago

...which allowed my site to work once again (phew!)
The error messages are now conveniently tagged with a correct Central timezone stamp, a la:
[16-May-2013 16:48:36 America/Chicago] PHP Warning: Module 'timezonedb' already loaded in Unknown on line 0

I am suspecting this has something to do with a bug in the server's installation or configuration of .php (and therefore I will not be able to fix the constant creation of these error messages). But I am open to suggestion.

If it DOES look like a server-based glitch that the "powers that be" must fix does anybody here know anything specific I can suggest that these folks look at?

Thanks.

dalecosp

Some INI file has the extension loaded twice, most likely.

dalecosp

Run [man]phpinfo/man, find all lines containing "ini" (either case) that refer to a file, and look (or have them look) in all those file for the timezonedb setting/extension.

Here's some sample output from a devel box:

Configuration File (php.ini) Path => /usr/local/etc
Loaded Configuration File => /usr/local/etc/php.ini
Scan this dir for additional .ini files => /usr/local/etc/php
Additional .ini files parsed => /usr/local/etc/php/extensions.ini
user_ini.cache_ttl => 300 => 300
user_ini.filename => .user.ini => .user.ini
init_command_executed_count => 0
init_command_failed_count => 0
com_init_db => 0
Classes => AppendIterator, ArrayIterator, ArrayObject, BadFunctionCallException, BadMethodCallException, CachingIterator, CallbackFilterIterator, DirectoryIterator, DomainException, EmptyIterator, FilesystemIterator, FilterIterator, GlobIterator, InfiniteIterator, InvalidArgumentException, IteratorIterator, LengthException, LimitIterator, LogicException, MultipleIterator, NoRewindIterator, OutOfBoundsException, OutOfRangeException, OverflowException, ParentIterator, RangeException, RecursiveArrayIterator, RecursiveCachingIterator, RecursiveCallbackFilterIterator, RecursiveDirectoryIterator, RecursiveFilterIterator, RecursiveIteratorIterator, RecursiveRegexIterator, RecursiveTreeIterator, RegexIterator, RuntimeException, SplDoublyLinkedList, SplFileInfo, SplFileObject, SplFixedArray, SplHeap, SplMinHeap, SplMaxHeap, SplObjectStorage, SplPriorityQueue, SplQueue, SplStack, SplTempFileObject, UnderflowException, UnexpectedValueException

So, if it was happening on this box, it would be likely they have the "timezonedb" module listed in both /usr/local/etc/php.ini and in /usr/local/etc/php/extensions.ini ...

HTH,

Joseph_Sliker

Thanks for these replies. The support reps for the host are now looking in to this. I forwarded the link to this discussion to them. I will mark this "resolved" as it is pretty clear the ability to fix this problem is out of my hands.

Joseph_Sliker

further follow-up: the solution that the host support people put into place for my site was to create a custom php.ini file an place it in the root directory, the contents of which are as follows (the very top line is apparently the "fix")

;extension=timezonedb.so
register_globals = Off

zend_extension="/usr/local/IonCube/ioncube_loader_lin_4.4.so"
zend_extension_ts="/usr/local/IonCube/ioncube_loader_lin_4.4_ts.so"

[Zend]
zend_optimizer.optimization_level=15
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.0
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.0
zend_optimizer.version=3.3.0

zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so

....although it appears to be working, it kind of feels like this is a "kludge"...that they did not fix something that was wrong with the overall configuration of php on their server. The tech who responded indicated that they will need to use this same type of solution for other php users.

MORE follow-up:

Gah! I just ran some tests and find that now NO ERRORS are being logged at all! Not exactly what I wanted...I make LOTS of errors in my coding and it's a big help to see these.

Guess I should not have closed that ticket yet. Back to the drawing board.

bradgrafelman

Joseph Sliker;11028373 wrote:
I just ran some tests and find that now NO ERRORS are being logged at all!

But if you've got your own custom php.ini file now, then things like error reporting are completely under your control; it should be a simple matter of setting the appropriate error_reporting level combined with the desired display_errors, log_errors, etc. settings.