/sbin/service can ignore any complex locale settings in /etc/sysconfig/i18n, when invoked under "pty" terminal (xterm, remote ssh etc.) Consider a case (fragment from /etc/sysconfig/i18n): LANG=ru_RU.UTF-8 LC_MESSAGES=C For the proper support of our locale (non-ascii input etc.etc.), we have to specify the LANG variable. But we want the messages to be in ancient C locale, not our native locale. Such settings are used often enough IMHO. 1. Consider /sbin/services script. It always run the appropriate initscript by: > env -i LANG="$LANG" PATH="$PATH" ... in other words, it drops our LC_MESSAGES, leaving the LANG only. 2. Most of the initscripts include /etc/init.d/functions. Since Fedora 7, it had changed in the place: if [ -f /etc/sysconfig/i18n -a -z "${NOLOCALE:-}" ] ; then - . /etc/sysconfig/i18n + . /etc/profile.d/lang.sh When /etc/sysconfig/i18n was used immediately, the LC_MESSAGES setting was set again. Now lang.sh is used instead. 3. /etc/profile.d/lang.sh, since Fedora 7, has changes in: sourced=0 + +if [ -n "$LANG" ]; then + sourced=1 +else for langfile in /etc/sysconfig/i18n $HOME/.i18n ; do [ -f $langfile ] && . $langfile && sourced=1 done +fi As we have invoked the initscript with LANG set (see 1. ), the i18n files is not sourced here. 4. Further in /etc/profile.d/lang.sh: when consoletype is "vt", then, fortunately, it sources /etc/sysconfig/i18n again (before /bin/unicode_start). This explains why there is no such an effect on the Linux "vt" console. But if consoletype is not "vt" (i.e. "pty", from xterm or ssh), then nothing sourced. In the last case we have LANG only, not LC_MESSAGES. Hence all messages are according to the common LANG setting, not our specific LC_MESSAGES setting. How to reproduce: - specify in your /etc/sysconfig/i18n, for example: LANG=de_DE.UTF-8 LC_MESSAGES=C - in the xterm or gnome-terminal, run "services ...something... {start or stop}" Messages should be in English (C locale), but are in German. As this issue also affects the remote ssh sessions, it is harmful enough. It prevents the ssh administring from non-desktop devices (PDA, modern cellular phones, old and dumb laptops, etc.)
Attempting to encode every potential locale setting in service seems to be a bad idea; this can be easily worked around by invoking the script directly. With respect to it not re-reading /etc/sysconfig/i18n, this is due to the change for bug 229102. With respect to it re-reading it on the console, that is because of 229996; that is best fixed by moving those initializations to udev callouts. I'm not sure there's anything here that can be fixed.
> this can be easily worked around by invoking the script directly. /etc/rc.d/init.d/script something ? ... :( Could you consider some further ideas how to fix this? Then I could start on a patch. Say your ideas here. I can shell scripting since 1992, hence can help... Perhaps /sbin/service could be changed some way, to export not LANG only? The "LANG=xx_XX.UTF-8 LC_MESSAGES=C" case IMHO is widely used by non-English developers, who prefer to see all messages as it was "written in the program" . For fprintf (stderr, _("this is not working")); as a developer, I prefer to see the same "this is not working" on the stderr, whereas the "end user" prefers to see a message on the native language. On the other hand, I have to specify LANG properly, at least to say that I use unicode. Certainly, in the context of the end users (say, RHEL customers), it is a corner case. But any active OpenSource developer is "a corner case" in that context as well. ;) IOW, this case is not "corner" for developers, who work under the Linux desktop. It is better to handle the issue someway...
(In reply to comment #2) > > this can be easily worked around by invoking the script directly. > > /etc/rc.d/init.d/script something ? ... :( Correct. > Could you consider some further ideas how to fix this? Then I could start on a > patch. Say your ideas here. I can shell scripting since 1992, hence can help... Well, you could extend each 'env' call in /sbin/service to explicitly enumerate all locale entries. But that gets very messy very quick.
*** Bug 443253 has been marked as a duplicate of this bug. ***
What we want is consistency. Either talk the language of the system (remove LANG from the "env -i" call) or the language of the current user session (in that case, add also LC_MESSAGES and LANGUAGE to the call). So choose between: 1) env -i PATH="$PATH" TERM="$TERM" "${SERVICEDIR}/${SERVICE}" ${OPTIONS} 2) env -i PATH="$PATH" TERM="$TERM" LANG="$LANG" LC_MESSAGES="$LC_MESSAGES" LANGUAGE="$LANGUAGE" "${SERVICEDIR}/${SERVICE}" ${OPTIONS} Option 1) would be safer because isn't the idea of /sbin/service to make sure the service is started using the system settings..?
Any chances it could be fixed in the future? AT least add to some TODO lists...
I really think this should be fixed simply by removing LANG from the "env -i" call. The script "${SERVICEDIR}/${SERVICE}" will set LANG anyway - and to the system's LANG. I think /sbin/service should behave that way anyway (use system settings - not the settings from the user's session). There is absolutely no reason to keep LANG in that "env -i" call "just in case". The "${SERVICEDIR}/${SERVICE}" script will always set LANG because all the scripts source /etc/rc.d/init.d/functions which contains sourcing for /etc/profile.d/lang.sh scripts which sets LANG etc. This is easy to fix.
http://git.fedorahosted.org/git/?p=initscripts.git;a=commit;h=73a91036b96450f976c5e45d3478d4b6f905c79a Done that way for the F10 development cycle, we'll see what breaks.