The Python function locale.setlocale() raises an exception if the local modification fails. We are not handling this gracefully, but instead crashing. Example: $ LANG=xx /opt/thinlinc/libexec/tl-select-profile Traceback (most recent call last): File "/opt/thinlinc/libexec/tl-select-profile", line 254, in <module> locale . setlocale ( locale . LC_ALL , "" ) File "/usr/lib64/python2.6/locale.py", line 513, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting We should either just ignore the error, or consider printing a warning. Most tools seems just to ignore bad locales: $ LC_ALL=xxx ls /doesnotexist ls: cannot access /doesnotexist: No such file or directory This is also what our C based programs do: tlclient, vncviewer etc. Bash does not though: $ LC_ALL=xxx bash bash: warning: setlocale: LC_ALL: cannot change locale (xxx)
This is an issue in vsmagent as well. SSH:ed in to a Ubuntu 12.04 machine from my Fedora workstation, ran install-server and tl-setup in text mode. tl-setup fails to start services and asks you to contact support. > root@ubuntu:~/tl-4.1.0-server# tail -n 18 /var/log/tlsetup.log > 2013-06-20 04:15:39,103: Starting services... > 2013-06-20 04:15:39,103: Starting service 'vsmagent'... > 2013-06-20 04:15:39,285: Output: > 2013-06-20 04:15:39,286: Shutting down ThinLinc vsmagent > 2013-06-20 04:15:39,286: Starting ThinLinc vsmagent > 2013-06-20 04:15:39,286: Traceback (most recent call last): > 2013-06-20 04:15:39,286: File "/opt/thinlinc/sbin/vsmagent", line 22, in <module> > 2013-06-20 04:15:39,286: VSMAgent ( sys . argv ) > 2013-06-20 04:15:39,286: File "/opt/thinlinc/modules/thinlinc/vsm/vsmagent.py", line 103, in __init__ > 2013-06-20 04:15:39,286: check_vsmagent_environment ( self . tlprefix , self . pidfile , self . hive ) > 2013-06-20 04:15:39,286: File "/opt/thinlinc/modules/thinlinc/vsm/checkenvironment.py", line 102, in check_vsmagent_environment > 2013-06-20 04:15:39,286: oOo0oooo00o ( ) > 2013-06-20 04:15:39,286: File "/opt/thinlinc/modules/thinlinc/vsm/checkenvironment.py", line 50, in oOo0oooo00o > 2013-06-20 04:15:39,286: locale . setlocale ( locale . LC_CTYPE , "" ) > 2013-06-20 04:15:39,286: File "/usr/lib/python2.7/locale.py", line 539, in setlocale > 2013-06-20 04:15:39,287: return _setlocale(category, locale) > 2013-06-20 04:15:39,287: locale.Error: unsupported locale setting > 2013-06-20 04:15:39,287: Failed to start service 'vsmagent' > root@ubuntu:~/tl-4.1.0-server# locale > locale: Cannot set LC_CTYPE to default locale: No such file or directory > locale: Cannot set LC_ALL to default locale: No such file or directory > LANG=en_US.UTF-8 > LANGUAGE= > LC_CTYPE=sv_SE.utf8 > LC_NUMERIC=sv_SE.utf8 > LC_TIME=sv_SE.utf8 > LC_COLLATE=sv_SE.utf8 > LC_MONETARY=sv_SE.utf8 > LC_MESSAGES=en_US.utf8 > LC_PAPER=sv_SE.utf8 > LC_NAME=sv_SE.utf8 > LC_ADDRESS=sv_SE.utf8 > LC_TELEPHONE=sv_SE.utf8 > LC_MEASUREMENT=sv_SE.utf8 > LC_IDENTIFICATION=sv_SE.utf8 > LC_ALL=
Does this cause the profile selector to crash?
(In reply to Peter Åstrand from comment #0) > Bash does not though: > > $ LC_ALL=xxx bash > bash: warning: setlocale: LC_ALL: cannot change locale (xxx) For some odd reason bash only does this for $LC_ALL, not $LANG. Perhaps a side effect of some other mechanism? bash has some very complex code for handling the locale environment variables.
This problem is much more prevalent now that we have added "setlocale()" calls to all of our Python programs as of bug 7571. Since it seems most programs will print a warning but still try to continue in this case - ThinLinc should probably do the same.
A few of these cases were fixed as part of bug 7571, but not all.
It seems newer versions of sshd has some sort of fallback for the case where you connect bringing a locale environment which isn't installed. I had two test servers, a Debian 10 with sshd v7.9, and a Fedora 33 with sshd v8.4. Both sshd servers were configured identically regarding the "AcceptEnv" configuration param. Both servers did not have the sv_SE.utf8 locale installed. When connecting like this: LANG=sv_SE.utf8 ssh user@server I got different results when checking the environment variables once connected. The resulting locale environment on the server with the old sshd gets mixed en_US.UTF-8 and sv_SE.UTF-8. This is broken and many programs, even 'locale' itself will complain about the broken setup. The machine with the new sshd gets a mix of en_US.UTF-8 and C.UTF-8 which isn't broken since both those locales are installed on the server.
We also encounted this crash with tl-collect-licensestats on Ubuntu 20.04 after using localectl to set an unavailable locale.
