Debian 6, MySQL

I can confirm the same in Ukrainian and Russian locales in the latest trunk rev 22380.

Cannot reproduce this problem with default graphs from "Linux template", does this problem occur on all graphs or only specific ones?

<pavels> Can't reproduce it too.

<zalex> Still can reproduce in the rev 23335. Any idea how to check the differences in our systems?

<richlv> php versions, gd versions ?
on the second thought, gd version shouldn't matter

for the record, can't reproduce in trunk rev 23404.
php 5.3.3 and 5.3.5
tried both simple & custom graphs with ukrainian and german locales.
tried custom graphs with multiple items on same axis, with two axis.

just a quick idea, have mo files been remade recently ?

Reproducible as mentioned above:

1. uname -a
   Linux it0 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64 GNU/Linux

1. cat /etc/debian_version
   6.0.3

1. dpkg -l | grep php
   ii libapache2-mod-php5 5.3.3-7+squeeze3 server-side, HTML-embedded scripting language (Apache 2 module)
   ii php5 5.3.3-7+squeeze3 server-side, HTML-embedded scripting language (metapackage)
   ii php5-cli 5.3.3-7+squeeze3 command-line interpreter for the php5 scripting language
   ii php5-common 5.3.3-7+squeeze3 Common files for packages built from the php5 source
   ii php5-gd 5.3.3-7+squeeze3 GD module for php5
   ii php5-mcrypt 5.3.3-7+squeeze3 MCrypt module for php5
   ii php5-mysql 5.3.3-7+squeeze3 MySQL module for php5
   ii php5-pgsql 5.3.3-7+squeeze3 PostgreSQL module for php5
   ii php5-suhosin 0.9.32.1-1 advanced protection module for php5

1. locale
   LANG=en_GB.UTF-8
   LC_CTYPE="en_GB.UTF-8"
   LC_NUMERIC="en_GB.UTF-8"
   LC_TIME="en_GB.UTF-8"
   LC_COLLATE="en_GB.UTF-8"
   LC_MONETARY="en_GB.UTF-8"
   LC_MESSAGES="en_GB.UTF-8"
   LC_PAPER="en_GB.UTF-8"
   LC_NAME="en_GB.UTF-8"
   LC_ADDRESS="en_GB.UTF-8"
   LC_TELEPHONE="en_GB.UTF-8"
   LC_MEASUREMENT="en_GB.UTF-8"
   LC_IDENTIFICATION="en_GB.UTF-8"
   LC_ALL=

1. locale -a
   C
   en_GB.utf8
   POSIX
   ru_RU.utf8
   uk_UA.utf8

The problem ***NOT*** reproducible on:

1. uname -a
   FreeBSD 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010

1. pkg_info | grep php
   php5-5.3.6_1 PHP Scripting Language
   php5-bcmath-5.3.6_1 The bcmath shared extension for php
   php5-ctype-5.3.6_1 The ctype shared extension for php
   php5-dom-5.3.6_1 The dom shared extension for php
   php5-gd-5.3.6_1 The gd shared extension for php
   php5-gettext-5.3.6_1 The gettext shared extension for php
   php5-mbstring-5.3.6_1 The mbstring shared extension for php
   php5-mysql-5.3.6_1 The mysql shared extension for php
   php5-session-5.3.6_1 The session shared extension for php
   php5-snmp-5.3.6_1 The snmp shared extension for php
   php5-sockets-5.3.6_1 The sockets shared extension for php
   php5-xml-5.3.6_1 The xml shared extension for php
   php5-xmlreader-5.3.6_1 The xmlreader shared extension for php
   php5-xmlwriter-5.3.6_1 The xmlwriter shared extension for php

1. locale
   LANG=uk_UA.UTF-8
   LC_CTYPE="uk_UA.UTF-8"
   LC_COLLATE="uk_UA.UTF-8"
   LC_TIME="uk_UA.UTF-8"
   LC_NUMERIC="uk_UA.UTF-8"
   LC_MONETARY="uk_UA.UTF-8"
   LC_MESSAGES="uk_UA.UTF-8"
   LC_ALL=

1. locale -a | wc -l
   172

1. locale -a | grep en_GB
   en_GB.ISO8859-1
   en_GB.ISO8859-15
   en_GB.US-ASCII
   en_GB.UTF-8

Could it have something to do with Suhosin patch?

Reproducible on:

1. uname -a
   Linux sl04121 2.6.32-5-686 #1 SMP Fri Sep 9 20:51:05 UTC 2011 i686 GNU/Linux

1. cat /etc/debian_version
   6.0.2

1. dpkg -l | grep php
   ii libapache2-mod-php5 5.3.3-7+squeeze3 server-side, HTML-embedded scripting language (Apache 2 module)
   ii php5-cli 5.3.3-7+squeeze3 command-line interpreter for the php5 scripting language
   ii php5-common 5.3.3-7+squeeze3 Common files for packages built from the php5 source
   ii php5-gd 5.3.3-7+squeeze3 GD module for php5
   ii php5-mysql 5.3.3-7+squeeze3 MySQL module for php5
   ii php5-suhosin 0.9.32.1-1 advanced protection module for php5

1. locale
   LANG=de_DE.UTF-8
   LC_CTYPE="de_DE.UTF-8"
   LC_NUMERIC="de_DE.UTF-8"
   LC_TIME="de_DE.UTF-8"
   LC_COLLATE="de_DE.UTF-8"
   LC_MONETARY="de_DE.UTF-8"
   LC_MESSAGES="de_DE.UTF-8"
   LC_PAPER="de_DE.UTF-8"
   LC_NAME="de_DE.UTF-8"
   LC_ADDRESS="de_DE.UTF-8"
   LC_TELEPHONE="de_DE.UTF-8"
   LC_MEASUREMENT="de_DE.UTF-8"
   LC_IDENTIFICATION="de_DE.UTF-8"
   LC_ALL=

1. locale -a
   C
   de_DE.utf8
   en_GB.utf8
   POSIX

suhosin might be easy to test - uninstalling/disabling it & trying again should reveal that

Right
I tested it - no difference. So it's not related to suhosin.

Same error seems to be with latest data. I attached two more images with that view.
Maybe there is a hint where to look for the error (latest-data-german.jpg) - include/func.inc.php:499.

I can confirm the same problems for latest data page as Jens mentioned.
But without php errors.

Not reproducible (trunk r 23438):

1. cat /etc/redhat-release
   CentOS release 5.5 (Final)

1. rpm -qa | grep php
   php-mbstring-5.3.5-1.el5.remi.1
   php-cli-5.3.5-1.el5.remi.1
   php-xml-5.3.5-1.el5.remi.1
   php-pdo-5.3.5-1.el5.remi.1
   php-ldap-5.3.5-1.el5.remi.1
   php-mysql-5.3.5-1.el5.remi.1
   php-common-5.3.5-1.el5.remi.1
   php-sqlite-5.3.5-1.el5.remi.1
   php-snmp-5.3.5-1.el5.remi.1
   php-5.3.5-1.el5.remi.1
   php-gd-5.3.5-1.el5.remi.1
   php-mcrypt-5.3.5-1.el5.remi.1
   php-bcmath-5.3.5-1.el5.remi.1

1. locale
   LANG=en_US.UTF-8
   LC_CTYPE="en_US.UTF-8"
   LC_NUMERIC="en_US.UTF-8"
   LC_TIME="en_US.UTF-8"
   LC_COLLATE="en_US.UTF-8"
   LC_MONETARY="en_US.UTF-8"
   LC_MESSAGES="en_US.UTF-8"
   LC_PAPER="en_US.UTF-8"
   LC_NAME="en_US.UTF-8"
   LC_ADDRESS="en_US.UTF-8"
   LC_TELEPHONE="en_US.UTF-8"
   LC_MEASUREMENT="en_US.UTF-8"
   LC_IDENTIFICATION="en_US.UTF-8"
   LC_ALL=

1. locale -a | wc -l
   650

1. locale -a | grep en_GB
   en_GB
   en_GB.iso88591
   en_GB.iso885915
   en_GB.utf8

On Debian 6.0.3 (mentioned above) the problem is still reproducible after replacing "php5 5.3.3-7+squeeze3" to the "php5 5.3.8.0-1"

Does systems where error is reproducible has bcmath extensions for php? And are all required extensions installed (passed requirements test during installation)?

<zalex> On Debian 6.0.3 I have installed libapache2-mod-php5 ->
Description: The following extensions are built in: bcmath bz2 calendar Core ctype date dba dom ereg exif fileinfo filter ftp gettext hash iconv json libxml mbstring mhash openssl pcre Phar posix Reflection session shmop SimpleXML soap sockets SPL standard sysvmsg sysvsem sysvshm tokenizer wddx xml xmlreader xmlwriter zip zlib.
Of course during installation no any errors.

This looks similar to ZBX-2582, but I have not reproduced it so far using the scenario with Trac mentioned in that issue.

Zabbix uses the "en" locale for LC_NUMERIC, it seems it doesn't work on some of these machines. Is it possible that there is no "en" locale available? Could you run "locale -a"?

<zalex> output for all mentioned OS added. see comments above.

What you say about these lines:

1. grep -r LC_NUMERIC *
   include/views/administration.users.edit.php:setLocale(LC_NUMERIC, array('en', 'en_US', 'en_US.UTF-8', 'English_United States.1252')); // numeric Locale to default
   include/config.inc.php: setLocale(LC_NUMERIC, array('en', 'en_US', 'en_US.UTF-8', 'English_United States.1252'));
   jsLoader.php: setLocale(LC_NUMERIC, array('en', 'en_US', 'en_US.UTF-8', 'English_United States.1252'));

I'm and Jens we both had only "en_GB" locale installed but not the "en_US".
When I installed "en_US" locale the problem is gone!

In the Debian it's command "dpkg-reconfigure locales"
Apache has to be restarted to apply installed locales: service apache2 restart

Pavels, you know what to do next.
Thanks.

<pavels> Yeah, sorry, I forgot to mention, that we currently use en_US.

Please review the fix for 1.8 in branches/dev/ZBX-4235 and for the trunk in branches/dev/ZBX-4235-trunk.

RESOLVED.

Note:
(1) If I removed both locales "en_GB" and "en_US" and restart apache, zabbix frontend still works correctly in English GUI.
But no any errors, warnings, etc to user that default locales are missing. Maybe it's ok and maybe not. It's up to you.
Tested Debian 6.0.3

<pavels> Then their default local must use periods as decimal points. I have an idea how to fix it without depending on locales, I'll give it a try Monday.

Dev branch (for trunk) tester. Works as expected for non-english GUI with installed only one locale of "en_GB" or "en_US".
Thanks.

I've added the POSIX locale as an alternative LC_NUMERIC locale. It should be supported on all *nix systems and it also uses a dot as a decimal separator.

Merged to trunk revision r23618 and branches/1.8 revision r23615.

CLOSED.