Bug 697015

By a restart, do you mean a SIGHUP of a running daemon (service httpd reload) rather than a stop and start?

The ini files are alpha-sorted before being parsed so if the ordering is correct, and it seems to be, it should work.

I ran it a few different ways, but it seems to always come up now, regardless of whether I use service httpd stop/start, reload, restart, or graceful. 
The reason why I said specifically not graceful before is because I wasn't sure if that was a factor in why this problem hadn't always been a problem for me.

It seems that the alpha ordering is not making a distinction between '.' and '_'.
When I do ls -l /etc/php.d:
...
-rw-r--r--. 1 root root   59 Apr  4 11:55 pdo_dblib.ini
-rw-r--r--. 1 root root   65 Jul 20  2010 pdo_informix.ini
-rw-r--r--. 1 root root   47 Apr  4 11:55 pdo.ini
-rw-r--r--. 1 root root   59 Apr  4 11:55 pdo_mysql.ini
-rw-r--r--. 1 root root   57 Apr  4 11:55 pdo_odbc.ini
-rw-r--r--. 1 root root   59 Apr  4 11:55 pdo_pgsql.ini
-rw-r--r--. 1 root root   61 Apr  4 11:55 pdo_sqlite.ini
...

I realize that the files are not necessarily loaded in the same order as ls displays them, but it seems to coincide that way (I haven't looked at the source code to tell how it does it).

The ordering above does not work for me (I see the warnings in the error_log), where as the following does work (no warnings):
...
-rw-r--r--. 1 root root   47 Apr  4 11:55 pdo_0.ini
-rw-r--r--. 1 root root   59 Apr  4 11:55 pdo_dblib.ini
-rw-r--r--. 1 root root   65 Jul 20  2010 pdo_informix.ini
-rw-r--r--. 1 root root   59 Apr  4 11:55 pdo_mysql.ini
-rw-r--r--. 1 root root   57 Apr  4 11:55 pdo_odbc.ini
-rw-r--r--. 1 root root   59 Apr  4 11:55 pdo_pgsql.ini
-rw-r--r--. 1 root root   61 Apr  4 11:55 pdo_sqlite.ini
...

File order is environment dependant

# LANG=C ls /etc/php.d/pdo*
/etc/php.d/pdo.ini
/etc/php.d/pdo_dblib.ini
/etc/php.d/pdo_firebird.ini
/etc/php.d/pdo_mysql.ini
/etc/php.d/pdo_oci.ini
/etc/php.d/pdo_odbc.ini
/etc/php.d/pdo_pgsql.ini
/etc/php.d/pdo_sqlite.ini

# LANG=fr_FR.utf8 ls /etc/php.d/pdo*
/etc/php.d/pdo_dblib.ini
/etc/php.d/pdo_firebird.ini
/etc/php.d/pdo.ini
/etc/php.d/pdo_mysql.ini
/etc/php.d/pdo_oci.ini
/etc/php.d/pdo_odbc.ini
/etc/php.d/pdo_pgsql.ini
/etc/php.d/pdo_sqlite.ini

So it seems you have change the value of HTTPD_LANG in /etc/sysconfig/httpd

My user environment is en_US.utf8, but the /etc/sysconfig/httpd does not have LANG set. So I guess the problem is that when I (re)start the Apache service, it's using my LANG environment variable instead of the default since LANG is defined in the environment.

I explicitly set HTTPD_LANG=C in /etc/sysconfig/httpd, but I'm still seeing the warnings in the error_log after restarting Apache.

Re-affecting to F16 and to httpd

I reproduce the bug which seems specific to systemd (never encounter this with SysV script)

Workaround found, in /lib/systemd/system/httpd.service

Environment=LANG=C


@Steven : can you confirm this workaround also work for you ?

Unfortunately I no longer have the environment where I was seeing the issue. My current Fedora 16 install does not seem to have this problem, but I know I don't have everything the same way I did before.

@Joe: with sysV init script we have

in /etc/sysconfig/httpd
  #HTTPD_LANG=C 

And in 
  HTTPD_LANG=${HTTPD_LANG-"C"}
  LANG=$HTTPD_LANG daemon --pidfile=${pidfile} $httpd $OPTIONS

So httpd is launch with choosen LANG (default to C)

With systemd, we don't have any solution to set LANG correctly, which explain this issue

Proposal:

Move, in /etc/sysconfig/httpd
From
  #HTTPD_LANG=C
To
  # Be aware than other locale could change extension load order
  LANG=C

And we'll get the same behavior

Ah, good catch Remi - yes, that'd be it.  That changes already done in f17/f18.  For f16 it's perhaps safer to make the change directly in the .service script, otherwise the init script itself will change LANG which is probably not desirable (the service script output is i18n'ed, I think?)

"init script output" I meant there.

Commit: http://pkgs.fedoraproject.org/gitweb/?p=httpd.git;a=commitdiff;h=6f5dcf52de776112b1dbb0d43aef7365d8819fd5

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.