Bug #54250 [Com]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
Edit report at http://bugs.php.net/bug.php?id=54250&edit=1 ID: 54250 Comment by: maciej at wiercinski dot net Reported by:maciej at wiercinski dot net Summary:date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call Status: Bogus Type: Bug Package:Date/time related Operating System: Linux 2.6 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: I thought you've meant triggering "pecl upgrade" upon installing the new version of php-timezone package. Previous Comments: [2011-03-17 00:10:44] ras...@php.net No it won't. You can distribute a binary pecl extension without needing "PECL". I'm not even sure what you mean by "PECL" here. An individual pecl extension is just a simple shared library. Nothing more. -------------------- [2011-03-17 00:02:47] maciej at wiercinski dot net ras...@php.net: It will still force them to distribute PECL (may be a concern for people building embedded/very small systems shipped with PHP). I don't really know PHP code, had just a very brief look at the patch itself and related functions, so what I'm saying may be completely invalid. What about compiling timezone data into dynamically loaded library, which they could ship separately of PECL/PHP itself / easily replace with calls to theirs? [2011-03-16 22:56:15] ras...@php.net Why not just make pecl/timezone dependent on the system timezone update. It seems easy enough to me. Your PHP package depends on pecl/timezone and pecl/timezone depends on the system timezone package. That should keep it all in synch. -------------------- [2011-03-16 22:52:34] maciej at wiercinski dot net johan...@php.net: I can see at least two problems Debian (and other distribution) maintainers will have with the solution you have proposed. They would have to make PHP dependent on PECL, which is currently not the case (at least not in Debian). On other hand it will eventually lead to a situation in which PHP's timezone update has been rolled out and system's not, or vice-versa. [2011-03-16 18:56:32] johan...@php.net vJust a small comment on > The PHP tzdata changes are mixed in with the > mainline development, and sometimes depend on > other changes within the engine, so it's not > really feasible to cherry pick out the changes > into a stable release, even if we wanted to. This is not true. Distributions can distribute the timezone update using the pecl/timzeone package. No messing with engine stuff needed. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=54250 -- Edit this bug report at http://bugs.php.net/bug.php?id=54250&edit=1
Bug #54250 [Com]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
Edit report at http://bugs.php.net/bug.php?id=54250&edit=1 ID: 54250 Comment by: maciej at wiercinski dot net Reported by:maciej at wiercinski dot net Summary:date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call Status: Bogus Type: Bug Package:Date/time related Operating System: Linux 2.6 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: ras...@php.net: It will still force them to distribute PECL (may be a concern for people building embedded/very small systems shipped with PHP). I don't really know PHP code, had just a very brief look at the patch itself and related functions, so what I'm saying may be completely invalid. What about compiling timezone data into dynamically loaded library, which they could ship separately of PECL/PHP itself / easily replace with calls to theirs? Previous Comments: [2011-03-16 22:56:15] ras...@php.net Why not just make pecl/timezone dependent on the system timezone update. It seems easy enough to me. Your PHP package depends on pecl/timezone and pecl/timezone depends on the system timezone package. That should keep it all in synch. [2011-03-16 22:52:34] maciej at wiercinski dot net johan...@php.net: I can see at least two problems Debian (and other distribution) maintainers will have with the solution you have proposed. They would have to make PHP dependent on PECL, which is currently not the case (at least not in Debian). On other hand it will eventually lead to a situation in which PHP's timezone update has been rolled out and system's not, or vice-versa. [2011-03-16 18:56:32] johan...@php.net vJust a small comment on > The PHP tzdata changes are mixed in with the > mainline development, and sometimes depend on > other changes within the engine, so it's not > really feasible to cherry pick out the changes > into a stable release, even if we wanted to. This is not true. Distributions can distribute the timezone update using the pecl/timzeone package. No messing with engine stuff needed. [2011-03-15 18:52:29] seanius at debian dot org Hi guys, We'll take up further discussion on the bug over there, but thought I would cut/paste the (slightly amended) initial response here just for posterity's sake. === Hi Maciej, Does this actually cause a quantifiable and significant performance regression? This possibility of performance issues was discussed some time ago but it was decided that the stat calls would just hit the kernel fs cache and not cause any serious problems. If there are indeed problems, there are certainly ways this could be worked around, but it would add even further complexity to the patch which we'd all prefer to avoid if possible. To give you some extra background, since the PHP authors certainly have their own take on the situation: EVERY serious linux distribution ships this patch in some form. Redhat, Fedora, Debian, Ubuntu, SLES, Opensuse (okay, maybe not Gentoo, but anyway...) all ship with this patch. So please keep that in mind when you here both sides of this argument :) The problem is that when the OS distributors release a timezone update, they don't want to *also* have to go package by package updating individual and "customized" timezone databases that might be embedded in a given application. Neither do they want to continuously update the version of PHP in their "stable" releases and have to deal with the numerous regressions that would result. The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is a point of disagreement with the PHP authors, who want to have control over this aspect of the engine themselves (and they certainly have their justifications, such as systems with outdated or nonexistant tzdata, plus they add some extra TZ annotations in their private copy). Unfortunately they are not interested in providing any other way to work around this issue, despite the periodic overture from us or RedHat. The invitation is still open to try and find a reasonable technical solution for this, but I have been led to beleive that Derick has really dug in his heels on the issue and it's not worth any of our time to raise a big stink about it. ----------------
Bug #54250 [Com]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
Edit report at http://bugs.php.net/bug.php?id=54250&edit=1 ID: 54250 Comment by: maciej at wiercinski dot net Reported by:maciej at wiercinski dot net Summary:date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call Status: Bogus Type: Bug Package:Date/time related Operating System: Linux 2.6 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: johan...@php.net: I can see at least two problems Debian (and other distribution) maintainers will have with the solution you have proposed. They would have to make PHP dependent on PECL, which is currently not the case (at least not in Debian). On other hand it will eventually lead to a situation in which PHP's timezone update has been rolled out and system's not, or vice-versa. Previous Comments: [2011-03-16 18:56:32] johan...@php.net vJust a small comment on > The PHP tzdata changes are mixed in with the > mainline development, and sometimes depend on > other changes within the engine, so it's not > really feasible to cherry pick out the changes > into a stable release, even if we wanted to. This is not true. Distributions can distribute the timezone update using the pecl/timzeone package. No messing with engine stuff needed. [2011-03-15 18:52:29] seanius at debian dot org Hi guys, We'll take up further discussion on the bug over there, but thought I would cut/paste the (slightly amended) initial response here just for posterity's sake. === Hi Maciej, Does this actually cause a quantifiable and significant performance regression? This possibility of performance issues was discussed some time ago but it was decided that the stat calls would just hit the kernel fs cache and not cause any serious problems. If there are indeed problems, there are certainly ways this could be worked around, but it would add even further complexity to the patch which we'd all prefer to avoid if possible. To give you some extra background, since the PHP authors certainly have their own take on the situation: EVERY serious linux distribution ships this patch in some form. Redhat, Fedora, Debian, Ubuntu, SLES, Opensuse (okay, maybe not Gentoo, but anyway...) all ship with this patch. So please keep that in mind when you here both sides of this argument :) The problem is that when the OS distributors release a timezone update, they don't want to *also* have to go package by package updating individual and "customized" timezone databases that might be embedded in a given application. Neither do they want to continuously update the version of PHP in their "stable" releases and have to deal with the numerous regressions that would result. The PHP tzdata changes are mixed in with the mainline development, and sometimes depend on other changes within the engine, so it's not really feasible to cherry pick out the changes into a stable release, even if we wanted to. This is a point of disagreement with the PHP authors, who want to have control over this aspect of the engine themselves (and they certainly have their justifications, such as systems with outdated or nonexistant tzdata, plus they add some extra TZ annotations in their private copy). Unfortunately they are not interested in providing any other way to work around this issue, despite the periodic overture from us or RedHat. The invitation is still open to try and find a reasonable technical solution for this, but I have been led to beleive that Derick has really dug in his heels on the issue and it's not worth any of our time to raise a big stink about it. -------------------- [2011-03-15 13:01:55] maciej at wiercinski dot net Thanks for the update, it's indeed Debian's fault. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618462 [2011-03-14 19:36:38] der...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Complain at your distribution for messing it up. [2011-03-14 19:27:58] ras...@php.net I think this is going to make Derick's head
Bug #54250 [Com]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
Edit report at http://bugs.php.net/bug.php?id=54250&edit=1
ID: 54250
Comment by: maciej at wiercinski dot net
Reported by:maciej at wiercinski dot net
Summary:date_default_timezone_set stat()'s whole
/usr/share/zoneinfo upon first call
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Linux 2.6
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Thanks for the update, it's indeed Debian's fault.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618462
Previous Comments:
[2011-03-14 19:36:38] der...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Complain at your distribution for messing it up.
[2011-03-14 19:27:58] ras...@php.net
I think this is going to make Derick's head explode :)
This is likely due to the fact that Ubuntu patches PHP to use the system
timezone
info as opposed to the default bundled data. If you build a clean
version of PHP
on Ubuntu using the code we actually distribute, I think you will find
that the
problem goes away.
----
[2011-03-14 19:11:29] maciej at wiercinski dot net
Description:
Upon first call to date_default_timezone_set, PHP syscalls stat() on all
the
files in /usr/share/zoneinfo.
It can be easily checked by running:
$ strace -s 100 -r php -n -r"date_default_timezone_set('GMT');" 2>&1 |
grep
zoneinfo
On average Debian/Ubuntu system it accounts for little over 600
syscalls.
Reproduced on:
PHP 5.3.5-1 with Suhosin-Patch (cli) (built: Feb 19 2011 01:57:59)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH
PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 4 2010
03:25:57)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans
PHP 5.3.2-1ubuntu4.7 with Suhosin-Patch (cli) (built: Jan 12 2011
18:36:08)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
*Not* reproduced on:
PHP 5.3.3-0.dotdeb.1 with Suhosin-Patch (cli) (built: Oct 1 2010
08:49:29)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins
GmbH
Test script:
---
$ strace -s 100 -r php -n -r"date_default_timezone_set('GMT');" 2>&1 |
grep zoneinfo | head -10
0.000190 open("/usr/share/zoneinfo/",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
0.46 stat64("/usr/share/zoneinfo//localtime",
{st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
0.000112 stat64("/usr/share/zoneinfo//Zulu", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
0.000101 stat64("/usr/share/zoneinfo//WET", {st_mode=S_IFREG|0644,
st_size=1873, ...}) = 0
0.000100 stat64("/usr/share/zoneinfo//W-SU", {st_mode=S_IFREG|0644,
st_size=2194, ...}) = 0
0.98 stat64("/usr/share/zoneinfo//Universal",
{st_mode=S_IFREG|0644, st_size=118, ...}) = 0
0.000101 stat64("/usr/share/zoneinfo//UTC", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
0.99 stat64("/usr/share/zoneinfo//US", {st_mode=S_IFDIR|0755,
st_size=352, ...}) = 0
0.97 stat64("/usr/share/zoneinfo//UCT", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
0.99 stat64("/usr/share/zoneinfo//Turkey",
{st_mode=S_IFREG|0644, st_size=2721, ...}) = 0
$ strace -s 100 -r php -n -r"date_default_timezone_set('GMT');" 2>&1 |
grep zoneinfo | wc -l
626
--
Edit this bug report at http://bugs.php.net/bug.php?id=54250&edit=1
[PHP-BUG] Bug #54250 [NEW]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
From:
Operating system: Linux 2.6
PHP version: 5.3.5
Package: Date/time related
Bug Type: Bug
Bug description:date_default_timezone_set stat()'s whole /usr/share/zoneinfo
upon first call
Description:
Upon first call to date_default_timezone_set, PHP syscalls stat() on all
the
files in /usr/share/zoneinfo.
It can be easily checked by running:
$ strace -s 100 -r php -n -r"date_default_timezone_set('GMT');" 2>&1 | grep
zoneinfo
On average Debian/Ubuntu system it accounts for little over 600 syscalls.
Reproduced on:
PHP 5.3.5-1 with Suhosin-Patch (cli) (built: Feb 19 2011 01:57:59)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH
PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 4 2010
03:25:57)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans
PHP 5.3.2-1ubuntu4.7 with Suhosin-Patch (cli) (built: Jan 12 2011 18:36:08)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
*Not* reproduced on:
PHP 5.3.3-0.dotdeb.1 with Suhosin-Patch (cli) (built: Oct 1 2010 08:49:29)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH
Test script:
---
$ strace -s 100 -r php -n -r"date_default_timezone_set('GMT');" 2>&1 | grep
zoneinfo | head -10
0.000190 open("/usr/share/zoneinfo/",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
0.46 stat64("/usr/share/zoneinfo//localtime",
{st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
0.000112 stat64("/usr/share/zoneinfo//Zulu", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
0.000101 stat64("/usr/share/zoneinfo//WET", {st_mode=S_IFREG|0644,
st_size=1873, ...}) = 0
0.000100 stat64("/usr/share/zoneinfo//W-SU", {st_mode=S_IFREG|0644,
st_size=2194, ...}) = 0
0.98 stat64("/usr/share/zoneinfo//Universal",
{st_mode=S_IFREG|0644, st_size=118, ...}) = 0
0.000101 stat64("/usr/share/zoneinfo//UTC", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
0.99 stat64("/usr/share/zoneinfo//US", {st_mode=S_IFDIR|0755,
st_size=352, ...}) = 0
0.97 stat64("/usr/share/zoneinfo//UCT", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
0.99 stat64("/usr/share/zoneinfo//Turkey", {st_mode=S_IFREG|0644,
st_size=2721, ...}) = 0
$ strace -s 100 -r php -n -r"date_default_timezone_set('GMT');" 2>&1 | grep
zoneinfo | wc -l
626
--
Edit bug report at http://bugs.php.net/bug.php?id=54250&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54250&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54250&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54250&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54250&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54250&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54250&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54250&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54250&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54250&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54250&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54250&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54250&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54250&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54250&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54250&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54250&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54250&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54250&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54250&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54250&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54250&r=mysqlcfg
