External Email - Use Caution
Greetings,
Several binaries in the Freesurfer 7.1.1 release appear to ignore (or misinterpret) system-wide locale settings. This causes a large number of errors to be reported throughout the recon process, particularly on startup. The commands appear to complete successfully despite the reported errors.
The errors are displayed as:
error: No such file or directory
error: Could not set locale
...repeated dozens of times.
A probably not exhaustive list of affected components:
strace output for one such command suggests that it's attempting to load the en_US locale, on a system where that is locale is not configured, and where system-wide settings indicate the something else should be used (eg: LANG=en_AU.UTF-8)
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=8896640, ...}) = 0
mmap(NULL, 8896640, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f727c65d000
close(3) = 0
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2995, ...}) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2995
read(3, "", 4096) = 0
close(3) = 0
openat(AT_FDCWD, "/usr/lib/locale/en_US/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en_US.utf8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en.utf8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(2, "error: ", 7error: ) = 7
write(2, "No such file or directory", 25No such file or directory) = 25
write(2, "\n", 1
) = 1
write(2, "error: ", 7error: ) = 7
write(2, "Could not set locale\0", 21Could not set locale^@) = 21
write(2, "\n", 1
) = 1
System info:
Debian 9.1.0 base system, using
freesurfer-linux-centos7_x86_64-7.1.1
Linux fmri-proc1 4.9.110-arc #1 SMP Tue Aug 14 17:45:49 CEST 2018 x86_64 GNU/Linux
Workaround:
Generating the en_US.UTF-8 locale, by adding/uncommenting the line "en_US.UTF-8 UTF-8" in /etc/locale.gen and re-running locale-gen effectively hides this problem.
Best regards,
Alex.