Bug 483409 - /etc/profile.d/lang.sh goes bonkers in a startup sequence with bash-4
Summary: /etc/profile.d/lang.sh goes bonkers in a startup sequence with bash-4
Keywords:
Status: CLOSED DUPLICATE of bug 482888
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-31 22:04 UTC by Michal Jaegermann
Modified: 2014-03-17 03:17 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-02 18:36:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2009-01-31 22:04:48 UTC
Description of problem:

I have LANG="en_CA.UTF-8" in /etc/sysconfig/i18n.  On a system startup I am greeted, immediately when an init sequence starts, with the following:

Switching to new root and running init.
/etc/profile.d/lang.sh: line 19: warning: setlocale: LC_CTYPE: cannot change loc
ale (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 20: warning: setlocale: LC_COLLATE: cannot change l
ocale (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 23: warning: setlocale: LC_MESSAGES: cannot change
locale (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 26: warning: setlocale: LC_NUMERIC: cannot change l
ocale (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 29: warning: setlocale: LC_TIME: cannot change loca
le (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 19: warning: setlocale: LC_CTYPE: cannot change loc
ale (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 20: warning: setlocale: LC_COLLATE: cannot change l
ocale (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 23: warning: setlocale: LC_MESSAGES: cannot change
locale (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 26: warning: setlocale: LC_NUMERIC: cannot change l
ocale (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 29: warning: setlocale: LC_TIME: cannot change loca
le (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 19: warning: setlocale: LC_CTYPE: cannot change loc
ale (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 20: warning: setlocale: LC_COLLATE: cannot change l
ocale (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 23: warning: setlocale: LC_MESSAGES: cannot change
locale (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 26: warning: setlocale: LC_NUMERIC: cannot change l
ocale (en_CA.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 29: warning: setlocale: LC_TIME: cannot change loca
le (en_CA.UTF-8): No such file or directory

Interestingly enough when some tracing is done one can see things like that:

....
+++ unset LC_IDENTIFICATION
+++ '[' -n '' ']'
+++ unset LC_MEASUREMENT
+++ '[' -n '' ']'
/etc/profile.d/lang.sh: line 26: warning: setlocale: LC_CTYPE: cannot change loc
ale (en_CA.UTF-8): No such file or directory
+++ '[' -n '' ']'
+++ unset LC_COLLATE
/etc/profile.d/lang.sh: line 27: warning: setlocale: LC_COLLATE: cannot change l
ocale (en_CA.UTF-8): No such file or directory
+++ '[' -n '' ']'
+++ unset LC_IDENTIFICATION
+++ '[' -n '' ']'
+++ unset LC_MEASUREMENT
+++ '[' -n '' ']'
+++ unset LC_MESSAGES
/etc/profile.d/lang.sh: line 30: warning: setlocale: LC_MESSAGES: cannot change
locale (en_CA.UTF-8): No such file or directory
....

In other words some 'unset' statements are fine but not others.  No idea why.

If I am trying to repeat the above from a running system, with an appropriate setting and unsetting variables involved - of course, then nothing happens.

There are two ways to prevent the above.
  - One is to revert to bash-3.
  - The other is to wrap the whole content of /etc/profile.d/lang.sh in
"if type -p locale >/dev/null; then ... ; endif".

Only the later appears to be a bogus "solution" as renaming /usr/bin/locale to something else does not allow to reproduce from a running system all these "cannot change locale".  Apparently this condition just delays attempts to really set LANG until all file systems are mounted.

With "fixed" /etc/profile.d/lang.sh and modified to print values of PWD, HOME and LANG before anything else is done I see in a startup this:
....
Enabling /etc/fstab swaps:                                 [  OK  ]
running /etc/profile.d/lang.sh
PWD /
HOME
LANG
Entering non-interactive startup
running /etc/profile.d/lang.sh
PWD /
HOME
LANG en_CA.UTF-8
iptables: Applying firewall rules:                         [  OK  ]
....

So setting of LANG happens only then and no error messages like those above show up.

Version-Release number of selected component (if applicable):
initscripts-8.89-1

How reproducible:
on every startup

Comment 1 Valdis Kletnieks 2009-02-01 08:04:13 UTC
I'm suspecting the base cause is that you have /usr/share as a separate file system, and it's doing this before /usr/share is mounted, so setlocale can't get to /usr/share/i18n/locales/en_U.

Also, this looks like a dup of bug #482888

Comment 2 Michal Jaegermann 2009-02-01 18:34:30 UTC
> Also, this looks like a dup of bug #482888

Yes, indeed, it does.

Does this also mean that bash-3 was simply ignoring those errors and bash-4 is just loud?  If this is indeed a matter of availability of /usr/share/locale
then running the whole thing inside "if [ -d /usr/share/locale ]; then ...; fi"
would help.

'lang.sh' is called all over the place in a startup sequence (which are really runs of /etc/profile).  Just 'echo' something from it and see for yourself.  It has even a code to prevent setting the same $LANG over and over.

Comment 3 Valdis Kletnieks 2009-02-02 16:21:04 UTC
No, *if* you get into /etc/profile.d/lang.sh, throwing those errors *is* proper.

The *bug* here is that /etc/profile (and thence /etc/profile.d/*.sh) are being called for /etc/rc.sysinit - *EVEN THOUGH IT'S A SCRIPT AND NOT A LOGIN SHELL*.

*THAT*'s what's broken here.

Comment 4 Michal Jaegermann 2009-02-02 18:02:45 UTC
> *THAT*'s what's broken here.

You mean that bash used in a startup runs as a login shell?  I have no idea if this is by design or by an accident.  Surely you need assorted settings, and that
includes LANG, be in a proper state before anything of X starts but that should be doable in any case.  Also if you want startup error messages "internationalized" (that happens now) then $LANG is required.

Comment 5 Bill Nottingham 2009-02-02 18:36:17 UTC

*** This bug has been marked as a duplicate of bug 482888 ***


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