Apache timezone and log timestamps
Lewis G Rosenthal
My PHP apps seem to respect my timezone setting in php.ini, configured
as Paul has recommended. However, my Apache logs are one hour off. I can
only attribute that to Apache not making the DST shift.
CONFIG.SYS says TZ=EST5EDT,3,2,0,7200,11,1,0,7200,3600 . For extra
measure, even though it should only impact CGI called from Apache, I
have the timezone set in httpd.conf to America/New_York. Still, Apache
seems to ignore the timezone.
Any suggestions? Confirmations? Workarounds?
TIA
--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE
Rosenthal & Rosenthal, LLC www.2rosenthals.com
Need a managed Wi-Fi hotspot? www.hautspot.com
Secure, stable, operating system www.ecomstation.com
-------------------------------------------------------------
Steven Levine
at 11:54 AM, Lewis G Rosenthal <lgros...@2rosenthals.com> said:
Hi,
>CONFIG.SYS says TZ=EST5EDT,3,2,0,7200,11,1,0,7200,3600 . For extra
>measure, even though it should only impact CGI called from Apache, I
>have the timezone set in httpd.conf to America/New_York. Still, Apache
>seems to ignore the timezone.
TZ issues in ported *nix apps are not unexpected. The TZ format you are
using is obsolete and designed by IBM for VAC apps. LIBC contains code
that can handle it, but it's always possible that the code is getting
bypassed somehow.
One possible solution is to set TZ in the wrapper script that starts
httpd. I've appended a CalcGMTOffset which contains logic to determine is
DST is active. You can rename it is IsDST and hack it to return isdst
rather than gmtoff and write code like
if IsDST() then
s = 'EST4'
else
s = 'EST5'
call value 'TZ', s, 'OS2ENVIRONMENT'
/* start httpd */
Steven
--
----------------------------------------------------------------------
"Steven Levine" <ste...@earthlink.net> eCS/Warp/DIY etc.
www.scoug.com www.ecomstation.com
----------------------------------------------------------------------
/*=== CalcGMTOffset(date) calculate GMT offset for today or passed date ===*/
CalcGMTOffset: procedure expose Env
/* Accepts full OS/2 style TZ but only uses GMT offset
Assumes standard US DST change points
Can pass date/time arg of form dd MMM yyyy if running OREXX
Must not pass date arg if running Classic REXX or will die here
*/
parse arg s
if s == '' then do
s = date('N')
dow = date('B') // 7 /* 6 = Sunday */
end
else
dow = date('B', s) // 7 /* 6 = Sunday */
dow = (dow + 1) // 7 /* Convert to 0 = Sunday */
/* say 'dow' dow */
parse var s dom mmm yy
tz = value('TZ',,Env)
/* say 'TZ' tz */
/* PST8PST,4, 1, 0, 3600,10, -1, 0, 7200,3600 */
parse var tz id','sm','sw','sd','st','em','ew','ed','et','shf
gmtoff = ''
i = verify(id, '0123456789+-', 'M')
if i > 1 then do
j = verify(id, '0123456789+-:', 'N', i)
if j = 0 then
j = length(id) + 1
s = substr(id, i, j - i)
parse var s hr':'min':'sec
gmtoff = ( - hr ) || right('00'min, 2)
end
/* Determine if DST - fixme for 2007 DST change
2006 - start 1st Sun Apr end last Sun Oct
2007 - start 2nd Sun Mar end 1st Sun Nov
*/
hr = time('H') /* fixme to be optional arg */
isdst = pos(mmm, 'AprMayJunJulAugSepOct') \= 0
if \ isdst then do
if mmm == 'Mar' then do
/* Find 2nd Sunday */
doms = dom + 7 - dow /* Next Sunday */
doms = doms - ((doms - 1) % 7) * 7 + 7 /* 2nd Sunday */
isdst = dom > doms | (dom = doms & hr >= 1)
end
else if mmm == 'Nov' then do
/* Find 1st Sunday */
doms = dom + 7 - dow /* Next Sunday */
doms = doms - ((doms - 1) % 7) * 7 /* First Sunday */
isdst = dom < doms | (dom = doms & hr < 2)
end
end
/* say 'doms' doms 'isdst' isdst */
if gmtoff == '' then
gmtoff = id /* TZ is really non-standard */
else do
if isdst then
gmtoff = gmtoff + 100 /* Spring forward */
if gmtoff < 0 then
gmtoff = '-' || right('00' || (- gmtoff), 4)
else
gmtoff = '+' || right('00' || gmtoff, 4)
end
/* say 'gmtoff' gmtoff */
return gmtoff
/* end CalcGMTOffset */
Lewis G Rosenthal
Simpler:
'SET TZ=EST5EDT4,M3.2,M11.1'
which is POSIX-compliant. I should have thought of that. My own
startup script actually had the TZ remmed out, per my notation that
Apache should get it from the master environment. I surely do know
that OS/2's TZ format is rather...ahem..."non-standard," so I should
have thought of using a POSIX string in its place. The question then
is whether the proper TZ will get handed off to CGI via the setting in
httpd.conf.
Anyway, the above seems to have doen the trick for the logs; thanks
for making me think into the problem a bit more. ;-)
Steven Levine
at 05:49 PM, "Lewis G Rosenthal" <lgros...@2rosenthals.com> said:
Hi,
>Simpler:
>'SET TZ=EST5EDT4,M3.2,M11.1'
>which is POSIX-compliant. I should have thought of that.
This may cause problems elsewhere. Unless I'm look at the wrong place,
LIBC expects a VAC style TZ setting.
See http://svn.netlabs.org/libc/browser/trunk/libc/src/libc/time/tzset.c
>The question then is whether the
>proper TZ will get handed off to CGI via the setting in httpd.conf.
Depends on which setting. If you mean the SetEnv directive, as the docs
say
"Sets an environment variable, which is then passed on to CGI scripts and
SSI pages."
Joe Suttle
Simpler:
'SET TZ=EST5EDT4,M3.2,M11.1' which is POSIX-compliant. I should have thought of that. My own startup script actually had the TZ remmed out, per my notation that Apache should get it from the master environment. I surely do know that OS/2's TZ format is rather...ahem..."non-standard," so I should have thought of using a POSIX string in its place. The question then is whether the proper TZ will get handed off to CGI via the setting in httpd.conf. Anyway, the above seems to have doen the trick for the logs; thanks for making me think into the problem a bit more. ;-)
The only place I can seem to find for setting an Apache timezone is in '.htaccess' files.
here is my 'startup.cmd'
= = = = =
@echo off
set TX=PST8PDT,3,2,0,7200,11,1,0,7200,3600
set beginlibpath=d:\apps\apache2\bin;d:\apps\apache2\modules;
d:\apps\apache2\bin\httpd -d . 2>&1
= = = = =
-- Joe Suttle * IBM Warp Certified System Expert * Member of IEEE joes...@attglobal.net http://www.joesuttle.com/blog Richmond, California http://www.warpedbox.com/ +----------------------------------------------------------------------+ "We learn something every day, and lots of times it's that what we learned the day before was wrong." -- Bill Vaughan +----------------------------------------------------------------------+ Using the power | WSeB, Apache, Weasel, FileStar of OS/2, Linux | Lotus SmartSuite, Firefox, Thunderbird, Kompozer and XP Pro | OpenSuse, Adtran, MySQL, PHP +----------------------------------------------------------------------+
Lewis G Rosenthal
On 09/26/09 01:58 pm, Joe Suttle thus wrote :
> Lewis G Rosenthal wrote:
>> Simpler:
>>
>> 'SET TZ=EST5EDT4,M3.2,M11.1'
>>
>> which is POSIX-compliant. I should have thought of that. My own
>> startup script actually had the TZ remmed out, per my notation that
>> Apache should get it from the master environment. I surely do know
>> that OS/2's TZ format is rather...ahem..."non-standard," so I should
>> have thought of using a POSIX string in its place. The question then
>> is whether the proper TZ will get handed off to CGI via the setting in
>> httpd.conf.
>>
>> Anyway, the above seems to have doen the trick for the logs; thanks
>> for making me think into the problem a bit more. ;-)
>>
> I tried this, and my log files are still an hour different than my
> system clock. PHP delivers the correct (system) time. When I put in
> your timezone as "PST8PDT7,M3.2,M11.1" my system goes crazy, and even
> PHP reports give some strange time (like 3:38 am on PHP vs 10:38am
> system clock vs 9:38 in log files).
My Apache logs were correct with the above string, but PHP seemed to
think that I was at GMT.
> Changing back to your long form "PST8PDT,3,2,0,7200,11,1,0,7200,3600"
> at least gets PHP to match system clock, even though the log files are
> still off an hour.
Indeed. Using Steve's method, my Apache logs were correct, but PHP was
then one hour off. :-) I'm with you; I'm dealing with my one-hour off
log files under Apache, as a trade-off for everything else seeming to
have the correct time (thanks for your post, which made me actually
*check* my PHP times).
> But, if as you guys say, Apache and cgi have to have the same time,
> and based on logs, they probably don't, that could account for why my
> cgi won't run. My PHP is running not as cgi, so that could be why it
> works, but not cgi.
>
Possibly, though I tend to doubt that the timezone offset would have
such a disasterous effect on your CGI, unless the CGI script itself is
trying to do some time calculatioin and ends up in a race condition.
> The only place I can seem to find for setting an Apache timezone is in
> '.htaccess' files.
>
No, TZ can be set in httpd.conf if mod_env is loaded (see
http://httpd.apache.org/docs/2.2/mod/mod_env.html ; use TZ values such
as America/Los_Angeles ).
> here is my 'startup.cmd'
> = = = = =
>
> @echo off
> set TX=PST8PDT,3,2,0,7200,11,1,0,7200,3600
> set beginlibpath=d:\apps\apache2\bin;d:\apps\apache2\modules;
> d:\apps\apache2\bin\httpd -d . 2>&1
>
Well, unless we're looking for a TX value, that should say TZ= . ;-)
However, as the TZ should already be set to that in your master
environment (i.e., via CONFIG.SYS), the above TZ variable is
superfluous, as you're simply repeating what's already there.
Zdenek Wagner
config.sys to CGI scripts (but I am not sure).
> Lewis
> -------------------------------------------------------------
> Lewis G Rosenthal, CNA, CLP, CLE
> Rosenthal & Rosenthal, LLC www.2rosenthals.com
> Need a managed Wi-Fi hotspot? www.hautspot.com
> Secure, stable, operating system www.ecomstation.com
> -------------------------------------------------------------
>
>
> >
>
Zdeněk Wagner
http://hroch486.icpf.cas.cz/wagner/
http://icebearsoft.euweb.cz
Steven Levine
at 05:58 PM, Lewis G Rosenthal <lgros...@2rosenthals.com> said:
Hi guys,
>My Apache logs were correct with the above string, but PHP seemed to
>think that I was at GMT.
That's probably because it's using a different routine to get the logging
time. A quick look says php uses apr_time() which calls libc's
gettimeofday().
Note that libc does not fully implement several TZ features. For example,
gettimeofday() says
pTZ->tz_dsttime = __libc_gTZInfo.dst; /** @todo Figure out
tz_dsttime! */
and tzset() says
/* TODO: POSIX.1 */
The former means that the dst offset may not be calculated correctly in
all cases. That later means that the results for your POSIX style TZ
setting are undefined.
>Indeed. Using Steve's method, my Apache logs were correct, but PHP was
>then one hour off. :-)
Do you mean the EST5 and EST4 method? If so, that's odd. DST should not
be an issue with this setting. Are you sure PHP is using this TZ value.
You can check this in your hello world script with getenv().
Lewis G Rosenthal
> In <4ABE8E9C...@2rosenthals.com>, on 09/26/09
> at 05:58 PM, Lewis G Rosenthal <lgros...@2rosenthals.com> said:
>
> Hi guys,
>
>
>> My Apache logs were correct with the above string, but PHP seemed to
>> think that I was at GMT.
>>
>
> That's probably because it's using a different routine to get the logging
> time. A quick look says php uses apr_time() which calls libc's
> gettimeofday().
>
> Note that libc does not fully implement several TZ features. For example,
> gettimeofday() says
>
> pTZ->tz_dsttime = __libc_gTZInfo.dst; /** @todo Figure out
> tz_dsttime! */
>
> and tzset() says
>
> /* TODO: POSIX.1 */
>
> The former means that the dst offset may not be calculated correctly in
> all cases. That later means that the results for your POSIX style TZ
> setting are undefined.
>
>
>> Indeed. Using Steve's method, my Apache logs were correct, but PHP was
>> then one hour off. :-)
>>
>
> Do you mean the EST5 and EST4 method? If so, that's odd. DST should not
> be an issue with this setting. Are you sure PHP is using this TZ value.
> You can check this in your hello world script with getenv().
>
>
PHP has several different methods for gleaning the timezone info.
* getenv('TZ') should return the OS' TZ variable, as passed to PHP
* The superglobals $_ENV or $_SERVER should return the TZ as set in
the server's environment, i.e., Apache, in our case
* apache_env('TZ') should return Apache's TZ (I guess the difference
between this and the superglobal would be that if running udner a
different server, we might not get an "apache" environment variable)
* date(DATE_RFC822) should return the current RFC822-formatted timestamp
So, a little fancy footwork (fingerwork), gets us:
<?php
error_log("Hello world from Mr. php.");
print "Hello from Mr. php. <p>" .
"Superglobal \$_ENV sees our timezone as " . $_ENV['TZ']
. "<br>" .
"getenv() sees our timezone as " . getenv('TZ') . "<br>" .
"apache_getenv() sees our timezone as " .
apache_getenv('TZ') . "<p>" .
"Thus, the current date & time is " . date(DATE_RFC822) .
"<p>";
?>
on my server, with the OS/2 TZ fooled into thinking it is -0400, yields:
Hello from Mr. php.
Superglobal $_ENV sees our timezone as
EST5EDT,3,2,0,7200,11,1,0,7200,3600
getenv() sees our timezone as America/New_York
apache_getenv() sees our timezone as America/New_York
Thus, the current date & time is Sun, 27 Sep 09 14:31:16 -0400
However, my log for the very "Hello from Mr. php." string, yields:
[27-Sep-2009 18:31:16] Hello world from Mr. php.
which is UTC.
As we already know that PHP is aware of the America/New_York setting
(which is also apparent from phpinfo() ), we can only surmise that the
logging facility does not utilize the date_timezone_set (the alias for
"DateTime::setTimezone").
Now, using a POSIX TZ string for Apache ('SET TZ=EST5EDT4,M3.2,M11.1'),
the above script yields the following:
Hello from Mr. php.
Superglobal $_ENV sees our timezone as EST5EDT4,M3.2,M11.1
getenv() sees our timezone as America/New_York
apache_getenv() sees our timezone as America/New_York
Thus, the current date & time is Sun, 27 Sep 09 10:41:21 -0400
(4 hours off) and the PHP error log says:
[27-Sep-2009 14:41:21] Hello world from Mr. php.
which is correct.
However, substituting EST4 as the TZ gets us:
Hello from Mr. php.
Superglobal $_ENV sees our timezone as EST4
getenv() sees our timezone as America/New_York
apache_getenv() sees our timezone as America/New_York
Thus, the current date & time is Sun, 27 Sep 09 14:52:46 -0400
which is okay, but this, in the log:
[27-Sep-2009 18:52:46] Hello world from Mr. php.
I haven't looked at the corresponding Apache log, but let's see...
[Sun Sep 27 14:52:44 2009] [notice] Apache/2.2.13 (OS/2) PHP/5.2.11
configured -- resuming normal operations
[Sun Sep 27 14:52:44 2009] [info] Server built: Sep 27 2009 10:25:33
which does look right. Thus, the EST4 workaround seems to solve *most*
of the problem, but not all of it. What I did last night was incorrect;
I didn't remove the balance of the TZ string when manually shifting to
EST4, so the one hour difference had to do with PHP calculating the DST
offset against EST4 (I had some trouble getting the REXX to work on my
setup, and didn't feel much like figuring it out at the time, so I just
cut to the chase - almost). :-)
I wonder if I was using Jonathan de Boyne Pollard's 32-bit CMD which
understands POSIX-compliant TZ variables whether it would make a
difference (not sure how it presents the TZ to applications which are
not POSIX-compliant)?
Lewis G Rosenthal
On 09/27/09 03:01 pm, Lewis G Rosenthal thus wrote :
> On 09/27/09 12:50 pm, Steven Levine thus wrote :
>
>> In <4ABE8E9C...@2rosenthals.com>, on 09/26/09
>> at 05:58 PM, Lewis G Rosenthal <lgros...@2rosenthals.com> said:
>>
>> Hi guys,
>>
>>
>>
>>> My Apache logs were correct with the above string, but PHP seemed to
>>> think that I was at GMT.
>>>
>>>
>> That's probably because it's using a different routine to get the logging
>> time. A quick look says php uses apr_time() which calls libc's
>> gettimeofday().
>>
>> Note that libc does not fully implement several TZ features. For example,
>> gettimeofday() says
>>
>> pTZ->tz_dsttime = __libc_gTZInfo.dst; /** @todo Figure out
>> tz_dsttime! */
>>
>> and tzset() says
>>
>> /* TODO: POSIX.1 */
>>
>> The former means that the dst offset may not be calculated correctly in
>> all cases. That later means that the results for your POSIX style TZ
>> setting are undefined.
>>
>>
<snip>
> Thus, the EST4 workaround seems to solve *most*
> of the problem, but not all of it.
No matter what, PHP *should* honor the setting in its .ini for the TZ,
but appears to not do that (at least under 5.2.11 and prior; I had to
backrev form 5.3.0, as Mantis 1.1.6 refused to run <sigh>).
The following might also be of interest (insofar as PHP is concerned;
not meaning to stray too far OT on this Apache list):
http://bugs.php.net/bug.php?id=45191 . At least I'm not the only one
with the complaint. ;-)
Steven Levine
at 03:01 PM, Lewis G Rosenthal <lgros...@2rosenthals.com> said:
Hi guys,
Snippage...
>I wonder if I was using Jonathan de Boyne Pollard's 32-bit CMD which
>understands POSIX-compliant TZ variables whether it would make a
>difference (not sure how it presents the TZ to applications which are
>not POSIX-compliant)?
Someone needs a nap... :-)
I believe there's a fix for all of this. The precursor to a fix is
turning on warnings (which requires no action here, because we are just
that way about this kind of stuff).
Letting hello.php do it's thing resulted in what is appended to the
message.
Anyway, the warning makes the fix obvious. Copying from the php.ini
sample and a bit of editing results in
[Date]
; Defines the default timezone used by the date functions
date.timezone = America/Los_Angeles
along with a couple of tweaks to populate $_ENV results in
Superglobal $_ENV sees our timezone as PST8PDT,3,2,0,7200,11,1,0,7200,3600
getenv() sees our timezone as PST8PDT,3,2,0,7200,11,1,0,7200,3600
apache_getenv() sees our timezone as PST8PDT,3,2,0,7200,11,1,0,7200,3600
Thus, the current date & time is Mon, 28 Sep 09 18:07:32 -0700
And the logs show
[Mon Sep 28 17:07:29 2009] [notice] Apache/2.2.13 (OS/2) PHP/5.3.0
configured -- resuming normal operations [Mon Sep 28 17:07:29 2009] [info]
Server built: Sep 27 2009 10:25:33 [Mon Sep 28 17:07:32 2009] [error]
[client 127.0.0.1] Hello world from Mr. php to the error log on Mon, 28
Sep 09 18:07:32 -0700.
Adjusting TZ to something less legacy results in
Superglobal $_ENV sees our timezone as PST7
getenv() sees our timezone as PST7
apache_getenv() sees our timezone as PST7
Thus, the current date & time is Mon, 28 Sep 09 18:11:00 -0700
and the logs say
[Mon Sep 28 18:10:57 2009] [notice] Apache/2.2.13 (OS/2) PHP/5.3.0
configured -- resuming normal operations [Mon Sep 28 18:10:57 2009] [info]
Server built: Sep 27 2009 10:25:33 [Mon Sep 28 18:11:00 2009] [error]
[client 127.0.0.1] Hello world from Mr. php to the error log on Mon, 28
Sep 09 18:11:00 -0700.
which I think is what we all want to see.
Steven
--
----------------------------------------------------------------------
"Steven Levine" <ste...@earthlink.net> eCS/Warp/DIY etc.
www.scoug.com www.ecomstation.com
----------------------------------------------------------------------
Hello from Mr. html.
Notice: Undefined index: TZ in D:\Internet\Apache22\mydocs\hello.php on line 10
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We had to select 'UTC' because your platform doesn't provide functionality for the guessing algorithm in D:\Internet\Apache22\mydocs\hello.php on line 13
Hello world from Mr. php.
Superglobal $_ENV sees our timezone as
getenv() sees our timezone as PST7
apache_getenv() sees our timezone as
Thus, the current date & time is Tue, 29 Sep 09 00:28:54 +0000
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We had to select 'UTC' because your platform doesn't provide functionality for the guessing algorithm in D:\Internet\Apache22\mydocs\hello.php on line 15
Steven Levine
at 03:12 PM, Lewis G Rosenthal <lgros...@2rosenthals.com> said:
Hi guys,
>No matter what, PHP *should* honor the setting in its .ini for the TZ,
>but appears to not do that (at least under 5.2.11 and prior; I had to
>backrev form 5.3.0, as Mantis 1.1.6 refused to run <sigh>).
You might want to check your settings. Backleveling to 5.2.8 results in
the browser output
Superglobal $_ENV sees our timezone as PST7
getenv() sees our timezone as PST7
apache_getenv() sees our timezone as PST7
Thus, the current date & time is Mon, 28 Sep 09 18:27:28 -0700
and the logs
[Mon Sep 28 18:27:21 2009] [notice] Apache/2.2.13 (OS/2) PHP/5.2.8
configured -- resuming normal operations [Mon Sep 28 18:27:21 2009] [info]
Server built: Sep 27 2009 10:25:33 [Mon Sep 28 18:27:28 2009] [error]
[client 127.0.0.1] Hello world from Mr. php to the error log on Mon, 28
Sep 09 18:27:28 -0700.
>The following might also be of interest (insofar as PHP is concerned;
>not meaning to stray too far OT on this Apache list):
>http://bugs.php.net/bug.php?id=45191 . At least I'm not the only one
>with the complaint. ;-)
Did you notice when the ticket was closed? :-)
Submitted: 5 Jun 2008 11:50pm UTC Modified: 3 May 7:09pm UTC From: info
at organicdata dot co dot za Assigned to: derick
Status: Closed Category: Date/time related
Lewis G Rosenthal
On 09/28/09 09:28 pm, Steven Levine thus wrote :
> In <4ABFB90F...@2rosenthals.com>, on 09/27/09
> at 03:12 PM, Lewis G Rosenthal <lgros...@2rosenthals.com> said:
>
> Hi guys,
>
>
>> No matter what, PHP *should* honor the setting in its .ini for the TZ,
>> but appears to not do that (at least under 5.2.11 and prior; I had to
>> backrev form 5.3.0, as Mantis 1.1.6 refused to run <sigh>).
>>
>
> You might want to check your settings. Backleveling to 5.2.8 results in
> the browser output
>
> Superglobal $_ENV sees our timezone as PST7
> getenv() sees our timezone as PST7
> apache_getenv() sees our timezone as PST7
>
> Thus, the current date & time is Mon, 28 Sep 09 18:27:28 -0700
>
> and the logs
>
> [Mon Sep 28 18:27:21 2009] [notice] Apache/2.2.13 (OS/2) PHP/5.2.8
> configured -- resuming normal operations [Mon Sep 28 18:27:21 2009] [info]
> Server built: Sep 27 2009 10:25:33 [Mon Sep 28 18:27:28 2009] [error]
> [client 127.0.0.1] Hello world from Mr. php to the error log on Mon, 28
> Sep 09 18:27:28 -0700.
>
>
Hmmm... My reference was to 5.2.9-5.2.11; I should have tried going back
farther this time. :-)
>> The following might also be of interest (insofar as PHP is concerned;
>> not meaning to stray too far OT on this Apache list):
>> http://bugs.php.net/bug.php?id=45191 . At least I'm not the only one
>> with the complaint. ;-)
>>
>
> Did you notice when the ticket was closed? :-)
>
> Submitted: 5 Jun 2008 11:50pm UTC Modified: 3 May 7:09pm UTC From: info
> at organicdata dot co dot za Assigned to: derick
> Status: Closed Category: Date/time related
>
>
Indeed, but the fix was noted in cvs at that time. I'm not certain what
version that would have been vs the versions I was testing (though
5.2.11 should have been after May 3).
Interesting, also, that your other post referencing 5.3.0 seemed to
respect that simple TZ setting. I need to see what's bothering Mantis
1.1.6 about PHP 5.3.0, and then look to moving back up to it.
Thanks for the follow-up!
Steven Levine
at 12:15 AM, Lewis G Rosenthal <lgros...@2rosenthals.com> said:
Hi,
>Interesting, also, that your other post referencing 5.3.0 seemed to
>respect that simple TZ setting. I need to see what's bothering Mantis
>1.1.6 about PHP 5.3.0, and then look to moving back up to it.
I still can't make Apache/2.2.13 (OS/2) PHP/5.3.0 with mysql enabled crash
easily enough to do useful debugging.
I did get one exception
Killed by SIGSEGV
pid=0x09d3 ppid=0x09ca tid=0x0001 slot=0x0085 pri=0x0200 mc=0x0001
D:\INTERNET\APACHE22\BIN\HTTPD.EXE
PHP5 0:005015b9
cs:eip=005b:0efe15b9 ss:esp=0053:0022fd80 ebp=0022fda8
ds=0053 es=0053 fs=150b gs=0000 efl=00012202
eax=00000004 ebx=00000000 ecx=00000001 edx=00000001 edi=002781c8
esi=002762f8 Process dumping was disabled, use DUMPPROC / PROCDUMP to
enable it.
but the setup was not correctly configured at the time. The trap is in
php5, but the maps I have are too old to provide useful info. Paul
shipped php5.dll with debug info which is why the binaries are so large.
I need to see if khll.exe can convert it to something useful.
Now that it's configured properly, I'm beating on httpd/php5 with the
latest phpmyadmin with no ill effects. Maybe I should see how dotProject
behaves. I've been meaning to bring to bring up a copy locally.
Lewis G Rosenthal
VOICE stuff to my box. In the added mix:
Mantis 1.1.6
MediaWiki 1.13.2
extensions: NamespacePermissions
Those are the only addtional PHP/MySQL apps which come to mind. Now,
whether the increase in the incidence of deamon restarts and stalls is
directly related to those apps and not just the additional traffic in
general, I can't say, however, I do see fairly persistent connections to
the PMMail MediaWiki site these days (and to the VOICE site, though
there's not much there which involves PHP, and nothing which directly
queries MySQL.
I suppose I should bump Mantis up to 1.1.8 and MW to 1.15.1 (MediaWiki
can be a real pain).
I just updated the WordPress sites on the system to the latest
available, but that hasn't made a difference. There are a couple
versions of Geeklog running, so I should probably go through those and
upgrade what needs to come up to the latest and greatest.
Do you think that the crashes we're seeing in the MySQL PHP module could
at all be caused by soemthing on the server side (the server is running
MySQL 5.0.67) vs the client version in the dll (5.1.37)?
Lewis G Rosenthal
Quick follow-up:
On 09/29/09 12:21 pm, Lewis G Rosenthal thus wrote :
<snip>
> Do you think that the crashes we're seeing in the MySQL PHP module could
> at all be caused by soemthing on the server side (the server is running
> MySQL 5.0.67) vs the client version in the dll (5.1.37)?
>
Just upgraded MySQL to 5.0.86 (NetWare), as the only 5.1 version I could
find was 5.1.19-beta. We'll see if that makes any kind of a difference
to Apache/PHP stability.
Steven Levine
at 12:21 PM, Lewis G Rosenthal <lgros...@2rosenthals.com> said:
Hi,
Snippage...
Upgrading to the latest stable version of an app is typically a good idea.
Bumping major versions (i.e. php 2.8 to 3.1) should be done with some
planning.
>Do you think that the crashes we're seeing in the MySQL PHP module could
>at all be caused by soemthing on the server side (the server is running
>MySQL 5.0.67) vs the client version in the dll (5.1.37)?
Hard to say. I'm still at 5.0.67 both client and server here and both
seem fine.
What we need to focus on is bumping up the logging so that we can see the
activity that is causing the httpd exit. This might require bumping the
php logging level.
I need to spend a bit more time to figure out how the code arrives that
the trapping call to DosUnsetExceptionHandler.