Linux

$ printf "test %f\n" 0,214
test 0,214000

$ env | grep LC_NU
LC_NUMERIC=da_DK

$ unset LC_NUMERIC      

$ printf "test %f\n" 0,214
-bash: printf: 0,214: invalid number
test 0.000000

$ printf "test %f\n" 0.214
test 0.214000

For some numeric conversions a radix character ("decimal point") or thousands' grouping character is used. The actual character used depends on the LC_NUMERIC part of the locale. The POSIX locale uses '.' as radix character, and does not have a grouping character. Thus,

printf("%'.2f", 1234567.89);
results in "1234567.89" in the POSIX locale, in "1234567,89" in the nl_NL locale, and in "1.234.567,89" in the da_DK locale.

ha, i mentioned that on my zabbixconf talk this year

but that's not a zabbix agent problem directly, is it ?
it only happens with userparameters. it is also not limited to the agent - same thing with external checks on server/proxy.

not much could be done besides setting locale in the initscripts or making zabbix accept comma (optionally)

edit : ah, just accepting the comma would not be enough as the separators could still mess up everything...

Could not reproduce the problem so far. Variables LC_XXX have no effect without a call to setlocale(), but we do not invoke setlocale() ourselves.

wiper and glebs.ivanovskis had an idea that setlocale() may be called by a library or a module that Zabbix agent uses. In order to find this out, they have prepared setlocale.c file (and an accompanying num_locale.c for testing, see attached).

In order to use this file, first compile the shared library from setlocale.c:

$ gcc setlocale.c -shared -fPIC -o setlocale.so -ldl

The purpose of this shared library is to track calls to setlocale(). So the next step would be to launch a Zabbix agent or another Zabbix binary as follows:

$ LD_PRELOAD=/path/to/setlocale.so zabbix_agentd ...

If there are any calls to setlocale(), they should appear in the Zabbix log file. Here is an example of how it should look like using num_locale.c file:

$ gcc num_locale.c -o num_locale
$ LD_PRELOAD=./setlocale.so ./num_locale
Probing environment variable LC_NUMERIC...
System locale is: "(null)"

Probing runtime locale settings...........
setlocale(1, "(null)") = "C"
./setlocale.so(+0x8d2)[0x7fde422078d2]
./setlocale.so(+0x945)[0x7fde42207945]
./setlocale.so(setlocale+0x27)[0x7fde4220796e]
./num_locale[0x400677]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fde41e7db45]
./num_locale[0x400559]
Runtime locale is: "C"; numbers look like: 1234567.8900

Setting runtime locale from environment...
setlocale(1, "") = "ru_RU.utf8"
./setlocale.so(+0x8d2)[0x7fde422078d2]
./setlocale.so(setlocale+0x27)[0x7fde4220796e]
./num_locale[0x4006c2]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fde41e7db45]
./num_locale[0x400559]
Runtime locale is: "ru_RU.utf8"; numbers look like: 1 234 567,8900

If the issue appears again, we can use the method documented above to investigate. For now, this issue should be closed as "Cannot Reproduce".

It does not seem to be mentioned in the issue description, but values like 97,677710 are returned by built-in items like system.cpu.util[].

ZBX-12383 provides an evidence that some of ODBC drivers call setlocale().

ZBX-13053 provides an evidence that Net-SNMP library calls setlocale() too.