Summary: | sys-apps/systemd: locale values aren't set by locale.conf | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pavel Volkov <ao> |
Component: | [OLD] Core system | Assignee: | Gentoo systemd Team <systemd> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander, amigadave, arnaudv6, arne.flagge, base-system, cschieli, fturco, leho, nikoli, paul, poncho, redneb |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: |
https://bugzilla.redhat.com/show_bug.cgi?id=663900 https://bugs.gentoo.org/show_bug.cgi?id=476756 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Migration code for sys-apps/systemd |
Description
Pavel Volkov
2013-04-11 06:28:04 UTC
(In reply to comment #0) > 3. run "localectl set-locale > LANG=ru_RU.utf8,LC_MESSAGES=en_US.utf8,LC_TIME=ja_JP.utf8" > /etc/locale.conf contains: > LANG=ru_RU.utf8,LC_MESSAGES=en_US.utf8,LC_TIME=ja_JP.utf8 > (same setup was in 02locale) With commas? o_O Commas in localectl commandline and locale.conf, newlines in /etc/env.d/02locale. Single assignment isn't working anyway. Using commas is not correct. You should execute this command: $ sudo localectl set-locale "LANG=ru_RU.utf8" "LC_MESSAGES=en_US.utf8" "LC_TIME=ja_JP.utf8" $ cat /etc/locale.conf LC_TIME=ja_JP.utf8 LANG=ru_RU.utf8 LC_MESSAGES=en_US.utf8 This seems like PEBKAC. ;) I already said that single assignments (only LANG=) don't work, too. This isn't a comma/newline problem. Current state: $ cat /etc/env.d/02locale # Configuration file for eselect # This file has been automatically generated. #LANG=ru_RU.utf8 #LC_MESSAGES=en_US.utf8 #LC_TIME=ja_JP.utf8 $ cat /etc/locale.conf LANG=ru_RU.utf8 LC_MESSAGES=en_US.utf8 LC_TIME=ja_JP.utf8 $ locale LANG= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= Just to chime in (keep in mind I no longer have the Gentoo box to provide further details) I had this exact same issue when removing 02locale and everything reporting as POSIX. I had locale set via systemd's file and command line as I have done in other distros and still no luck. I ended up exporting my desired locale at login. I actually had this in Arch Linux before they made the full switch and I had the exact same POSIX 'issue' until they moved their locale.sh in the filesystem package (I'm not sure on the specifics of where it was or doing at the time though). I actually encounter the exact same bug : confirming it so, plus I think 478190 is a duplicate of that one. ...and I encounter 474946 too, but it must not be related : locales are variables : they would not fail to set for paths reasons. Or would they ? actually, just realized that I am not using 205 version of systemd, but 201... And I'm about to upgrade to 204 for it just got keyworded. Still, I have interesting complement to previous post : root ~ # localectl list-locales en_US en_US.iso88591 en_US.utf8 fr_FR.iso885915@euro fr_FR.utf8@euro fr_FR@euro root ~ # localectl System Locale: LANG=fr_FR.utf8@euro VC Keymap: n/a X11 Layout: n/a root ~ # systemctl status localed.service localed.service Loaded: error (Reason: No such file or directory) Active: inactive (dead) there definetly exists a diference between gentoo's tree and the one systemd expects (fedora's one ?) Last time I tried to remove /etc/env.d/02locale with systemd-201, I also encounter this bug. (In reply to Arnaud Vallette d'Osia from comment #8) > root ~ # systemctl status localed.service > localed.service > Loaded: error (Reason: No such file or directory) > Active: inactive (dead) > > there definetly exists a diference between gentoo's tree > and the one systemd expects (fedora's one ?) The unit name is systemd-localed.service. *** Bug 478190 has been marked as a duplicate of this bug. *** I am copying what I wrote in #478190: I have the following in my /etc/locale.conf: LANG="en_US.UTF-8" LC_TIME="en_GB.UTF-8" Here's description of the problem (this is with systemd 201 & 204): * when I login using the linux console on tty1 or via ssh, none of the locale variables is set * when I run bash in gnome-terminal, only LANG is set (to "en_US.UTF-8") * when I run any graphical gnome application, only LANG is set for that application If I symlink /etc/env.d/02locale to /etc/locale.conf then everything works correctly but I think the locale should be set in one place only. For comparison, in arch linux with systemd, the only place where locale variables are set is /etc/locale.conf and everything works correctly. They do it by having the following lines in /etc/profile.d/locale.sh (among other things): if [ -r /etc/locale.conf ]; then . /etc/locale.conf fi I'll remove version number here. This is a possible trap for all gnome 3.8 users, because gnome is known for not working well within non unicode locales! (I am in systemd team since some weeks ago)(In reply to Evgeny Bobkin from comment #14) > This is a possible trap for all gnome 3.8 users, because gnome is known for > not working well within non unicode locales! -> wiki page was updated to point people to proper configuration steps until this is fixed, or do you think it should be improved (from a docs point of view)? :/ (In reply to Pacho Ramos from comment #15) > (I am in systemd team since some weeks ago)(In reply to Evgeny Bobkin from > comment #14) > > > > This is a possible trap for all gnome 3.8 users, because gnome is known for > > not working well within non unicode locales! > > -> wiki page was updated to point people to proper configuration steps until > this is fixed, or do you think it should be improved (from a docs point of > view)? :/ regarding the wiki and gnome docs, so far so good:) I meant, it looks like this bug report lost an attention of developers working on systemd integration. only Mike Gilbert in comment 4 looked at it quickly and marked as PEBKAC ("Problem Exists Between Keyboard And Chair") One of the possible solutions suggested in comment 12 is really trivial. just to include a file /etc/profile.d/locale.sh with the following context: if [ -r /etc/locale.conf ]; then . /etc/locale.conf fi Or is it more complicated? dir = opendir("/usr/lib/locale"); if (!dir) { log_error("Failed to open locale directory: %m"); return -errno; } Now, we do install /usr/lib64/locale wrong or is it their fault? AFAICS I've got 'locale' in lib64 and lib32, with identical contents. (In reply to Evgeny Bobkin from comment #16) [...] > if [ -r /etc/locale.conf ]; then > . /etc/locale.conf > fi > > Or is it more complicated? I doubt other devs will agree with changing where do we set locales to comply systemd :( Also, it would "hide" the problem of systemd not loading the file itself and we needing to use profile to load it :| (In reply to Pacho Ramos from comment #18) > I doubt other devs will agree with changing where do we set locales to > comply systemd :( Also, it would "hide" the problem of systemd not loading > the file itself and we needing to use profile to load it :| Is it possible to create a symlink /etc/locale.conf -> /etc/env.d/02locale for both localectl and locale loading to work? (In reply to Pavel Volkov from comment #19) > Is it possible to create a symlink /etc/locale.conf -> /etc/env.d/02locale > for both localectl and locale loading to work? It can be any number, and any sequence of letters in /etc/env.d/, for example, I'm using /etc/env.d/01local to set my locales next to other custom settings. I don't think using specific filename /etc/env.d/02locale has ever been mandatory in Gentoo, rather they get set the way env-update works. Just wondering, what's the upgrade path... if it is changed to locale.conf also for non-systemd users (In reply to Samuli Suominen from comment #20) > It can be any number, and any sequence of letters in /etc/env.d/, for > example, I'm using /etc/env.d/01local to set my locales next to other custom > settings. > I don't think using specific filename /etc/env.d/02locale has ever been > mandatory in Gentoo, rather they get set the way env-update works. The official way to set locale is 'eselect locale', but it does not support multiple variables, I think. If we assume that eselect does know the correct file in env.d (I don't know if it's fixed ot not), it could also create the symlink if it does not exist yet. People like you who use non-standard files can create it manually then. I don't think this is the best approach though. It will break if 'localectl set-locale' is initially called before 'eselect locale'. We should not need to symlink anything here; the shell is supposed to inherit the setting from the systemd process which starts it. I believe the real problem here are these lines in getty@.service: # Unset locale for the console getty since the console has problems # displaying some internationalized messages. Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION= This completely breaks the locale handling for console logins. We should try to get this fixed by systemd upstream. Adding link to related Fedora bug. Here is the relevent commit: commit 1640944a847249d3f5f0fb0d5a5f820a82efaed0 Author: Lennart Poettering <lennart@poettering.net> Date: Thu Jan 6 20:38:06 2011 +0100 getty: unset locale before execution On the console indian characters cannot be displayed, hence it is advisable to disable indian locales on the console, which most distributions traditionally did from a shell fragment executed post login. If getty gets started with locale settings passed it would itself however be translated without the no-indian-on-console fixup applied. Hence, for now don't pass any locale settings to getty/login, and thus rely on the classic post-login script fragment to set and fix the locale. Eventually we probably want to drop this again since the system locale should be read and set at one place, and not at multiple, and that one place should be PID 1. https://bugzilla.redhat.com/show_bug.cgi?id=663900 So basically, they got lazy and didn't fix it properly. I suppose we will need to implement a similar workaround. (In reply to Mike Gilbert from comment #22) > We should not need to symlink anything here; the shell is supposed to > inherit the setting from the systemd process which starts it. Unfortunately, it's not that simple. Locale variables are reset but many other programs as well. For example, /bin/login does it. So even if getty is started with the correct locale, it will be modified before the user logs in the linux console. I have discovered similar problems with other programs such as sshd and gdm. (In reply to redneb from comment #24) I am unable to reproduce the behavior you describe with /bin/login; after I remove those lines from getty@.service and reload systemd, the LANG setting is passed all the way down to my shell as I would expect. For sshd, we allow clients to set LANG and LC_* by default. See bug 367017. Last time I checked, GDM allows you to select your locale from a drop-down, so that behavior is intentional. (In reply to Samuli Suominen from comment #20) > (In reply to Pavel Volkov from comment #19) > > Is it possible to create a symlink /etc/locale.conf -> /etc/env.d/02locale > > for both localectl and locale loading to work? > > It can be any number, and any sequence of letters in /etc/env.d/, for > example, I'm using /etc/env.d/01local to set my locales next to other custom > settings. > I don't think using specific filename /etc/env.d/02locale has ever been > mandatory in Gentoo, rather they get set the way env-update works. > > Just wondering, what's the upgrade path... if it is changed to locale.conf > also for non-systemd users This symlink idea actually sounds like our best option at the moment. We could just have sys-apps/gentoo-systemd-integration create it in pkg_postinst if /etc/locale.conf does not exist. For existing users, we can ewarn if locale.conf is not a symlink to /etc/env.d/02locale. Any objections? (In reply to Mike Gilbert from comment #26) Actually, that won't work because localed unlinks /etc/locale.conf. We could do a symlink in the other direction though: /etc/env.d/02locale -> /etc/locale.conf (In reply to Mike Gilbert from comment #25) > (In reply to redneb from comment #24) > > I am unable to reproduce the behavior you describe with /bin/login; after I > remove those lines from getty@.service and reload systemd, the LANG setting > is passed all the way down to my shell as I would expect. Yes, the LANG variable is not reset by login. But try setting LC_TIME to something different. Same with gdm; some variables are preserved, some are not. (In reply to redneb from comment #28) Ah, I see. Thanks for the clarification. Created attachment 358744 [details, diff]
Migration code for sys-apps/systemd
Possible problems:
1. 02locale may contain setting that localed will ignore (like LC_ALL).
2. The user may have locale settings in some file other than 02locale.
Personally, I think this is "good enough" and we can ignore these problems since they will not affect many users.
(In reply to Mike Gilbert from comment #30) > Created attachment 358744 [details, diff] [details, diff] > Migration code for sys-apps/systemd What's wrong with the approach used by Fedora and Arch? They install script in /etc/profile.d, that source /etc/locale.conf and export all necessary veriables. Arch supply /etc/profile.d/locale.sh: see attachment in bug 478190 Fedora supply /etc/profile.d/lang.sh: see [1], this is the latest version according to [2]. [1] http://fedorahosted.org/releases/i/n/initscripts/initscripts-9.50.tar.bz2 [2] http://pkgs.fedoraproject.org/cgit/initscripts.git/tree/initscripts.spec (In reply to Alexander Tsoy from comment #31) > Fedora supply /etc/profile.d/lang.sh: see [1], this is the latest version > according to [2]. Direct link: https://git.fedorahosted.org/cgit/initscripts.git/tree/lang.sh Yeah, profile.d would work too. Might be a bit cleaner. Is there any specific difference between profile.d and env.d except for that env.d needs 'env-update' call? As for other distros, I'd really dislike Fedora's overkill. Arch's better but still, I think we shouldn't be going this way unless there's a well-approved ~/.config/locale.conf. The manpage says only about /etc/locale.conf. It also says: Depending on the operating system, other configuration files might be checked for locale configuration as well, however only as fallback. I don't know about unsetting (is there anything to unset?). env.d avoid the explicit 'export' line. Fixed in -207-r1. (In reply to Michał Górny from comment #17) you cannot hardcode a specific locale dir. it is an ABI-specific generated file (encodes things like alignment and endianness). i'm not sure why any file is even poking in that path when it only contains files meant for internal glibc use and uses a file format that is not guaranteed to be stable. |