Bug 422141 - /sbin/service locale weirdness
/sbin/service locale weirdness
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
: 443253 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-12-12 12:44 EST by Dmitry Butskoy
Modified: 2014-03-16 23:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-01 16:16:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dmitry Butskoy 2007-12-12 12:44:48 EST
/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):


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:

+if [ -n "$LANG" ]; then
+   sourced=1
 for langfile in /etc/sysconfig/i18n $HOME/.i18n ; do
     [ -f $langfile ] && . $langfile && sourced=1

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:


- 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.)
Comment 1 Bill Nottingham 2008-02-01 16:16:57 EST
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.
Comment 2 Dmitry Butskoy 2008-02-04 11:46:17 EST
> 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" .

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...

Comment 3 Bill Nottingham 2008-02-04 12:28:32 EST
(In reply to comment #2)
> > 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...

Well, you could extend each 'env' call in /sbin/service to explicitly enumerate
all locale entries. But that gets very messy very quick.
Comment 4 Bill Nottingham 2008-04-21 12:08:08 EDT
*** Bug 443253 has been marked as a duplicate of this bug. ***
Comment 5 Jarkko 2008-04-29 17:02:14 EDT
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:



Option 1) would be safer because isn't the idea of /sbin/service to make sure
the service is started using the system settings..?
Comment 6 Dmitry Butskoy 2008-05-08 13:06:16 EDT
Any chances it could be fixed in the future? AT least add to some TODO lists...
Comment 7 Jarkko 2008-05-08 13:39:21 EDT
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.
Comment 8 Bill Nottingham 2008-05-08 13:47:52 EDT

Done that way for the F10 development cycle, we'll see what breaks.

Note You need to log in before you can comment on or make changes to this bug.