Bug 25411 - Installing apache-mod_perl implies that setlocale has no effect in PHP
Summary: Installing apache-mod_perl implies that setlocale has no effect in PHP
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Marc Krämer
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-06 10:35 CEST by papoteur
Modified: 2019-10-14 12:28 CEST (History)
2 users (show)

See Also:
Source RPM: apache-mod_perl-2.0.10-6.mga7.x86_64
CVE:
Status comment:


Attachments

Description papoteur 2019-09-06 10:35:42 CEST
Description of problem:
setlocale instruction in PHP has no effect:
<?php
$date = "2019-08-31";
echo $date."<BR>";
echo strftime("%e %B %Y",strtotime($date)) . "<BR>";
setlocale(LC_TIME, "fr_FR.utf8");
echo strftime("%e %B %Y",strtotime($date));

According to documentation, and behaviour in Mageia 6, output of strftime is localized. But I get:
2019-08-31
31 August 2019
31 August 2019

I would expect that the last output would be:
31 août 2019

Version-Release number of selected component (if applicable):
lib64php_common7-7.3.8-1.mga7

How reproducible:
Save the previous code in test.php
Open in browser http://localhost/test.php
Comment 1 papoteur 2019-09-06 10:37:26 CEST
Assigning to maintainer.

Assignee: bugsquad => mageia

Comment 2 Marc Krämer 2019-09-06 11:29:25 CEST
did you try without ".utf8"?
setlocale(LC_TIME, "fr_FR");

Is this locale installed on your machine? Tested your code with en_US, de_DE which are my locales, runs without issues and correct results.
Marc Krämer 2019-09-06 11:29:53 CEST

Status: NEW => UNCONFIRMED
Ever confirmed: 1 => 0

Comment 3 papoteur 2019-09-06 11:39:07 CEST
Without utf8, same effect.
Know that my system is migrated from Mageia 6. These instructions were used in my application and was working in PHP7.2 before the migration.
My system is localized in French, of course.
locale
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=
Comment 4 papoteur 2019-09-06 11:50:11 CEST
And with fr_FR.UTF-8, same effect too.
Possible related problem: 
https://www.mageialinux-online.org/forum/topic-26353-1+nextcloud-vs-locales.php
Comment 5 Marc Krämer 2019-09-06 12:28:34 CEST
can you check the output of
setlocale() - it will return the locale that is in effect:
<?php
$date = "2019-01-31";
echo $date."\n";
echo setlocale(LC_TIME, "de_DE")."\n";
echo 'date:'.date(' F d.m.Y',strtotime($date))."\n";
echo '1:'.strftime("%e %B %Y",strtotime($date)) . "\n";
setlocale(LC_TIME, "en_GB");
echo '2:'.strftime("%e %B %Y",strtotime($date));
?>
$ php -v
PHP 7.3.8 (cli) (built: Aug  1 2019 09:43:08) ( NTS )
$ php test.php
2019-01-31
de_DE
date: January 31.01.2019
1:31 Januar 2019
2:31 January 2019

did you check /etc/php.ini.rpmnew and /etc/php.d/*.rpmnew
05_date.ini
may be relevant.
Comment 6 Marc Krämer 2019-09-06 12:33:18 CEST
I assume this will give you your package?
$ rpm -qa locales-fr

I've installed that package myself, switched "de_DE" to "fr_FR" and get:
2019-01-31
fr_FR
date: January 31.01.2019
1:31 janvier 2019
2:31 January 2019
Comment 7 papoteur 2019-09-06 12:41:46 CEST
With your code, from the console:
php test_locale.php 
2019-01-31
fr_FR
date: January 31.01.2019
1:31 janvier 2019
2:31 January 2019

But, from the browser:
2019-01-31 fr_FR date: January 31.01.2019 1:31 January 2019 2:31 January 2019

In this case, output 1 is not localized, although it is from the command line.
Is the php command line using the apache server?
Comment 8 papoteur 2019-09-06 13:11:47 CEST
rpm -qa locales-fr
locales-fr-2.29-3.mga7
Comment 9 Marc Krämer 2019-09-06 13:49:33 CEST
strange, currently I've no server running apache-mod-php anymore, all servers using php-fpm. On php-fpm, everything is ok.
Comment 10 papoteur 2019-09-06 15:43:55 CEST
Can php-fpm be substituted to apache-mod-php ?
Comment 11 Marc Krämer 2019-09-06 15:59:48 CEST
at least for security, memory and maintenace I suggest using php-fpm. By using php-fpm you do not depend on apache, but you can still use it, if you need or like it :)

Switching from mod-apache to php-fpm, you can use sockets or network to connect the php-fpm deamon. Each php-fpm process can run with a different user.
In apache you have to pass the file to the php-fpm process e.g. like this:

ProxyPassMatch ^/(.*\.php)$ unix:///var/run/php-fpm/www.sock|fcgi://127.0.0.1:9000/home/demo/www/ flushpackets=auto timeout=1800


You'll have to read some manual, php-fpm and proxying from apache is sometimes a bit complicated, but it is worth the work :)
Comment 12 HomeBoy TAZ 2019-09-16 18:38:18 CEST
Hi,

First, sorry for have not jumped into this thread earlier, as papoteur advised me, especially because he found this because of me (trying to figure out why my nextcloud was displaying some strange missing locales error).

I have made some more tests based on papoteur's ones:
- my production installation is also a migration from 6 to 7
- I have installed a VM, checking the setlocale working, then applied an upgrade to 7: the setlocale is still working
- I have tried your php-fpm but I might be missing something (according to your post, there is some customization to do), I have a 403 Forbidden: execute access forbidden (service is started)
- $locale_result=setlocale(LC_TIME, "fr_FR.utf8");
result is fr_FR.utf8
$locale_result=setlocale(LC_TIME, "fr_FR");
result is fr_FR
$locale_result=setlocale(LC_TIME, "fr_FR.UTF-8");
result is fr_FR.UTF-8
$locale_result=setlocale(LC_TIME, "fr_FR.utfZ8");
empty result (excepted behavior I assume with unknown locale)
- locale -a returns a long list of them, including the requested ones, the IS-88591 ones, @euro, ... I reinstalled the files without success
- locales-fr-2.29-3.mga7 ; apache-mod_php-7.3.9-1.mga7 ; lib64php_common7-7.3.9-1.mga7
- 05_date.ini: md5 on good&bad environments are equal

Let me know if I may try some other things
Thanks.

CC: (none) => nicolas.bachelet1

Comment 13 papoteur 2019-09-17 13:05:39 CEST
(In reply to Marc Krämer from comment #5)
> can you check the output of
> setlocale() - it will return the locale that is in effect:

I missed this question.
It returns nothing in the browser.
In command line, I get 
PHP Warning:  setlocale() expects at least 2 parameters, 0 given
Comment 14 papoteur 2019-09-17 17:39:33 CEST
Hi Marc,
I'm trying to set php-fpm, but fail.
I have installed 
php-fpm
apache-mod_proxy
apache-mod_proxy_html

I have a local application installed in /var/www/html/dolibarr which an index.php in directory htdocs
Usually I have access to it without virtualhost at localhost/dolibarr/htdocs.

I have launched php-fpm and restarted apache with default configuration. But I never got the socket at /var/lib/php-fpm/php-fpm.sock although this is set in /etc/php-fpm.d/www.conf
I have more success by setting access through net.
I built a virtualhost file setting the server at http://dolibarr which get the main page only, but not the other php files to laod are not found (error 404). I have in my virtualhost file:
<VirtualHost *:80>
ServerName dolibarr
ServerAlias dolibarr
UseCanonicalName On
AddDefaultCharset UTF-8
DocumentRoot "/var/www/html"
ProxyPassMatch ^/(.*\.php)$ fcgi://127.0.0.1:9000/var/www/html/dolibarr/htdocs/$1 flushpackets=auto timeout=1800
...

Have you some ideas?
Comment 15 HomeBoy TAZ 2019-09-28 13:35:45 CEST
Still no clue regarding what is broken in our environments or how/what to do to find the root cause?

I did not tried again php-fpm as we might still have our issue...
Comment 16 papoteur 2019-09-28 15:29:55 CEST
Hello,
I finally obtained that php-fpm works, using some mod_rewrite.
Thus, no explanation of the root cause.
Papoteur
Comment 17 Marc Krämer 2019-09-29 20:15:10 CEST
sorry for the delay, I was on vaccation.

Btw. you told it was working in mga6 using the apache module. Did it work with the backported php 7.2 or did you use php 5.6?
Comment 18 Marc Krämer 2019-09-29 23:35:36 CEST
sorry for the delay, I was on vaccation.

Btw. you told it was working in mga6 using the apache module. Did it work with the backported php 7.2 or did you use php 5.6?
Comment 19 Marc Krämer 2019-09-30 01:45:06 CEST
sorry for the delay, I was on vaccation.

Btw. you told it was working in mga6 using the apache module. Did it work with the backported php 7.2 or did you use php 5.6?
Comment 20 papoteur 2019-10-01 08:58:05 CEST
(In reply to Marc Krämer from comment #19)
> Btw. you told it was working in mga6 using the apache module. Did it work
> with the backported php 7.2 or did you use php 5.6?
For my side, I was using the backported php7.2
Comment 21 Marc Krämer 2019-10-01 14:35:47 CEST
ok, since there are no changes from php 7.2 to 7.3 on setlocale and the build process for php 7.2 and 7.3 are similar, it may be an general mga7 issue or some change in apache.
The documentation says "The return value of setlocale() depends on the system that PHP is running. It returns exactly what the system setlocale function returns."
So maybe apache prevents/blocks setting the locale. At least setlocale works on the process, not the thread so you can always encounter racing conditions using setlocale.
Comment 22 HomeBoy TAZ 2019-10-07 20:07:07 CEST
[root@machine ~]# urpme apache-mod_perl
To satisfy dependencies, the following 4 packages will be removed (3.6MB):
  apache-mod_perl-2.0.10-6.mga7.x86_64
  perl-SOAP-WSDL-3.3.0-4.mga7.noarch
   (due to missing perl(APR::Table),
    due to missing perl(Apache2::Const),
    due to missing perl(Apache2::Log),
    due to missing perl(Apache2::RequestIO),
    due to missing perl(Apache2::RequestRec))
  task-lamp-3-7.mga7.noarch
   (due to missing task-lamp-perl)
  task-lamp-perl-3-7.mga7.noarch
   (due to missing apache-mod_perl)
Remove 4 packages? (y/N) y
removing apache-mod_perl-2.0.10-6.mga7.x86_64 perl-SOAP-WSDL-3.3.0-4.mga7.noarch task-lamp-3-7.mga7.noarch task-lamp-perl-3-7.mga7.noarch
removing package perl-SOAP-WSDL-3.3.0-4.mga7.noarch
      1/4: removing perl-SOAP-WSDL-3.3.0-4.mga7.noarch
                                 #############################################
removing package task-lamp-1:3-7.mga7.noarch
      2/4: removing task-lamp-1:3-7.mga7.noarch
                                 #############################################
removing package task-lamp-perl-1:3-7.mga7.noarch
      3/4: removing task-lamp-perl-1:3-7.mga7.noarch
                                 #############################################
removing package apache-mod_perl-1:2.0.10-6.mga7.x86_64
      4/4: removing apache-mod_perl-1:2.0.10-6.mga7.x86_64
                                 #############################################
[root@machine ~]# service httpd restart
Redirecting to /bin/systemctl restart httpd.service

=> locales are working again in PHP
=> papoteur: do you confirm it solves your issue too?
=> do not know what/why...
Comment 23 Marc Krämer 2019-10-08 00:03:27 CEST
strange, so mod_perl has influence on mod_php...
Comment 24 papoteur 2019-10-08 08:38:52 CEST
Hello,
 urpme apache-mod_perl

This has no effect by me.
perl-SOAP-WSDL wasn't installed.
Comment 25 papoteur 2019-10-08 20:57:32 CEST
(In reply to papoteur from comment #24)
> Hello,
>  urpme apache-mod_perl
> 
> This has no effect by me.
> perl-SOAP-WSDL wasn't installed.

Sorry, I didn't restarted apache.
Now, after restarting, this is OK!
Should we consider apache-mod_perl as the culprit?

How to solve that?

Status: UNCONFIRMED => NEW
Ever confirmed: 0 => 1

papoteur 2019-10-14 10:44:04 CEST

Summary: setlocale has no effect in PHP => Installing apache-mod_perl implies that setlocale has no effect in PHP
Source RPM: php7.3 => apache-mod_perl-2.0.10-6.mga7.x86_64

Marc Krämer 2019-10-14 12:28:53 CEST

CC: (none) => shlomif


Note You need to log in before you can comment on or make changes to this bug.