Bug 482888 - Warnings from /etc/profile.d/lang.sh
Warnings from /etc/profile.d/lang.sh
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Roman Rakus
Fedora Extras Quality Assurance
:
: 483409 506063 507764 (view as bug list)
Depends On:
Blocks: F11Target
  Show dependency treegraph
 
Reported: 2009-01-28 12:50 EST by Mamoru TASAKA
Modified: 2014-01-12 19:08 EST (History)
25 users (show)

See Also:
Fixed In Version: 8.95.1-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-21 23:50:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch to fix locale handling of /etc/rc.d/rc (1.32 KB, patch)
2009-05-05 18:44 EDT, James Ralston
no flags Details | Diff

  None (edit)
Description Mamoru TASAKA 2009-01-28 12:50:56 EST
Description of problem:

From /var/log/boot.log:
-----------------------------------------------------------
Setting up hotplug.
Creating block device nodes.
Creating character device nodes.
Loading pata_acpi module
Loading ata_generic module
Making device-mapper control node
Scanning logical volumes
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup00" using metadata type lvm2
Activating logical volumes
  3 logical volume(s) in volume group "VolGroup00" now active
Creating root device.
Mounting root filesystem.
Setting up other filesystems.
Switching to new root and running init.
/etc/profile.d/lang.sh: line 19: warning: setlocale: LC_CTYPE: cannot change locale (ja_JP.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 20: warning: setlocale: LC_COLLATE: cannot change locale (ja_JP.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 23: warning: setlocale: LC_MESSAGES: cannot change locale (ja_JP.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 26: warning: setlocale: LC_NUMERIC: cannot change locale (ja_JP.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 29: warning: setlocale: LC_TIME: cannot change locale (ja_JP.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 19: warning: setlocale: LC_CTYPE: cannot change locale (ja_JP.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 20: warning: setlocale: LC_COLLATE: cannot change locale (ja_JP.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 23: warning: setlocale: LC_MESSAGES: cannot change locale (ja_JP.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 26: warning: setlocale: LC_NUMERIC: cannot change locale (ja_JP.UTF-8): No such file or directory
/etc/profile.d/lang.sh: line 29: warning: setlocale: LC_TIME: cannot change locale (ja_JP.UTF-8): No such file or directory
                Welcome to ESC[0;34mFedoraESC[0;39m 
                Press 'I' to enter interactive startup.
Starting udev: udevd[671]: specified group 'dialout' unknown
-----------------------------------------------------------

My /etc/sysconfig/i18n says:
-----------------------------------------------------------
LANG="ja_JP.UTF-8"
SUPPORTED="ja_JP.UTF-8:ja_JP:ja"
SYSFONT="latarcyrheb-sun16"
-----------------------------------------------------------

Version-Release number of selected component (if applicable):
initscripts-8.88-1.i386
(not tested 8.89-1)
glibc-2.9.90-2.i686

How reproducible:
Perhaps 100%

Steps to Reproduce:
1. reboot
2.
3.
Comment 1 Bill Nottingham 2009-01-28 13:18:42 EST
Is /usr a separate partition for you? When did this error start happening?
Comment 2 Mamoru TASAKA 2009-01-28 13:33:54 EST
(In reply to comment #1)
> Is /usr a separate partition for you? 
Yes.

> When did this error start happening?
Sorry, actually I didn't reboot for 25 days...
From boot.log-XXXX I cannot find out when this began.
Comment 3 Bill Nottingham 2009-01-28 14:03:44 EST
Stab in the dark - if you downgrade to bash 3.x, does this go away?
Comment 4 Mamoru TASAKA 2009-01-28 21:48:33 EST
(In reply to comment #3)
> Stab in the dark - if you downgrade to bash 3.x, does this go away?

Seems good. I tried to reboot with 3.2-33.fc11 initscripts-8.89-1.i386
and the warnings disappeared.

With bash-4.0-0.1.rc1.fc11 this is reproducible.
Comment 5 Bill Nottingham 2009-01-29 09:25:21 EST
Moving to bash. Is there a reason this is a loud error now?
Comment 6 Roman Rakus 2009-01-29 09:32:25 EST
This is probably the same problem as in bug #483002. Please try bash-4.0-0.3.rc1.fc11.
Comment 7 Mamoru TASAKA 2009-01-29 10:28:25 EST
bash-4.0-0.3.rc1.fc11 still reproduces this warning.

It seems that this warnings come from locale.c:
-------------------------------------------------------------
   187  #if defined (HAVE_SETLOCALE)
   188        r = *lc_all ? ((x = setlocale (LC_ALL, lc_all)) != 0) : reset_locale_vars ();
   189        if (x == 0)
   190          internal_warning("setlocale: LC_ALL: cannot change locale (%s): %s", lc_all, strerror(errno));
   191        locale_setblanks ();
   192        return r;
   193  #else
.......................
   239    if (x == 0)
   240      internal_warning("setlocale: %s: cannot change locale (%s): %s", var, get_locale_var (var), strerror(errno));
-------------------------------------------------------------
Comment 8 Valdis Kletnieks 2009-02-01 03:03:49 EST
Nope, this is a different issue than bug #483002 - that one is debugging output, this one is that setlocale is being invoked before /usr/share is mounted, so it can't get to /usr/share/i18n/locales/en_US or whatever it's looking for.

Why the bleep are we calling /etc/profile (and thence /etc/profile.d/*.sh) when we're handling /etc/rc.sysinit, anyhow?  SHouldn't the default behavior be --noprofile when running a shell script?  Or is /sbin/init doing something really evil with the execve() call?
Comment 9 Bill Nottingham 2009-02-02 13:36:17 EST
*** Bug 483409 has been marked as a duplicate of this bug. ***
Comment 10 Bill Nottingham 2009-02-02 13:37:59 EST
It's explicitly sourced, so that localization of the scripts actually works.
Comment 11 Michal Jaegermann 2009-03-06 12:37:53 EST
Complaints are still there.  Is making /etc/profile.d/lang.sh to check if /usr/share/i18n/locales/ directory is present and run only then really not an option? This looks quite simple and in an absence of /usr/share/i18n/locales/ what lang.sh tries to do will not work anyway.
Comment 12 Mamoru TASAKA 2009-03-27 10:22:45 EDT
Setting F11Target
Comment 13 Hedayat Vatankhah 2009-04-17 12:12:46 EDT
I see such errors too after upgrading to the latest glibc (in fact, glibc-common) package. Not only I see the error messages on boot, when I run any program in Gnome (in fa_IR locale), it says that it cannot find the locale and uses C locale. And all of the applications (except the main menu!) appear in English instead of Persian.
Comment 14 Hedayat Vatankhah 2009-05-03 13:45:58 EDT
While my system was running rawhide, I still saw that problem (I installed a Fedoba 11 beta Live CD, and updated it).  Anyway, I installed Fedora 11 Preview, and I don't see the problem anymore.
Comment 15 James Ralston 2009-05-05 16:59:10 EDT
I installed Fedora 11 Preview using this partitioning scheme:

clearpart --drives=vda --all --initlabel
part /boot --ondisk=vda --fstype ext3 --size=1024
part pv.0 --ondisk=vda --size=1024 --grow
volgroup vos --pesize=32768 pv.0
logvol swap --fstype swap --name=swap --vgname=vos --size=2048
logvol / --fstype ext4 --name=root --vgname=vos --size=1024
logvol /home --fstype ext4 --name=home --vgname=vos --size=1024
logvol /tmp --fstype ext4 --name=tmp --vgname=vos --size=1024
logvol /usr --fstype ext4 --name=usr --vgname=vos --size=4096
logvol /var --fstype ext4 --name=var --vgname=vos --size=1024
logvol /var/log --fstype ext4 --name=log --vgname=vos --size=1024
logvol /var/tmp --fstype ext4 --name=vtmp --vgname=vos --size=1024

...and I *am* still seeing the setlocale errors.

IMHO, this isn't so much a bug as it is a faulty assumption. There is no guarantee that / and /usr will not be separate partitions/volumes.
Comment 16 Bill Nottingham 2009-05-05 17:13:33 EDT
The reason I consider it a bug is that bash was not previously nearly as verbose in this situation.
Comment 17 James Ralston 2009-05-05 18:44:34 EDT
Created attachment 342553 [details]
patch to fix locale handling of /etc/rc.d/rc

I disagree. This isn't a bug with bash; it's a bug with the initscripts. Bash's old behavior merely hid the bug.

We must not explicitly source lang.sh if locale data is unavailable. But as soon as locale data is available, we *do* want to source lang.sh

This patch (against F10, because I don't have an F11 box handy ATM) attempts to source lang.sh as soon as it can, but will only source it once.
Comment 18 Bill Nottingham 2009-05-05 21:27:58 EDT
As stated, I disagree.

1) These warnings (not errors!) from bash do not come from setting the locale, but from calling *unset* on variables that have no value to begin with
2) Aside from these warnings, the behavior is, with no /usr, messages are in english until the locale data is available, at which point it switches to the defined locale
3) You're suggesting adding code to do lots of checks... which would just accomplish the behavior we already have
Comment 19 James Ralston 2009-06-01 11:38:24 EDT
In response to comment 18:

I don't necessarily disagree that it's bogus that bash prints these warnings multiple times (for "unset", no less).

But I don't see how we can argue that a program isn't entitled to warn when setlocale(3) fails.

If we don't want to see these warnings (or any warnings), the solution is simple: don't attempt to set the locale when the prerequisite data to do so (i.e., /usr/share/locale) isn't available. That's what my patch does.

Yes, my patch makes /etc/rc.d/rc test if locale data is available for each initscript it invokes. But that overhead is miniscule. Furthermore, once locale data becomes available, /etc/rc.d/rc remembers that (via LANGSH_SOURCED), so the test largely short-circuits.
Comment 20 Bug Zapper 2009-06-09 06:56:25 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 21 udo 2009-06-13 07:27:02 EDT
I can confirm I see them on an upgraded F11 i386 box (VIA En12000).
What is the current workaround?
Comment 22 Bill Nottingham 2009-06-16 17:25:58 EDT
*** Bug 506063 has been marked as a duplicate of this bug. ***
Comment 23 udo 2009-06-18 10:02:11 EDT
(In reply to comment #11)
> Complaints are still there.  Is making /etc/profile.d/lang.sh to check if
> /usr/share/i18n/locales/ directory is present and run only then really not an
> option? This looks quite simple and in an absence of /usr/share/i18n/locales/
> what lang.sh tries to do will not work anyway.  

Can't we just redirect the very UGLY error messages to /dev/null?

If so, what needs to be changed where so we can test?
Comment 24 Bill Nottingham 2009-06-18 10:47:14 EDT
http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=7932211055b0f66095ccb1a22cc03e07e2c64d54

Cherry-picked to the F11 branch as well.
Comment 25 udo 2009-06-18 11:04:29 EDT
test-rpm? :-)
Comment 26 Bill Nottingham 2009-06-24 10:32:26 EDT
*** Bug 507764 has been marked as a duplicate of this bug. ***
Comment 27 Marcos Aguinaldo Forquesato 2009-07-02 10:22:13 EDT
Can we redirect stderr to /dev/null?
Comment 28 Dominic Hopf 2009-08-18 10:02:50 EDT
Also noticed this behaviour on my machine, Fedora 11 with kernel-2.6.29.6-217.2.8.fc11.x86_64, initscripts-8.95-1.x86_64, bash-4.0-7.fc11.x86_64.
Comment 29 Panos Kavalagios 2009-09-30 04:38:51 EDT
We are still getting no love for having /usr on a separate filesystem. It may be only warnings, but they are really ugly and spoil our divine boot.log output.
Comment 30 Paul Rawson 2009-11-13 04:40:00 EST
On my system LANG="en_us" was set in /etc/sysconfig/i18n 
I changed en_us to en_US and the warnings went away.
Comment 31 udo 2009-11-14 03:31:43 EST
LANG="en_US.UTF-8" here. Why doesn't that help?
Comment 32 Fedora Update System 2009-12-05 10:22:36 EST
initscripts-8.95.1-1 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/initscripts-8.95.1-1
Comment 33 udo 2009-12-06 10:23:22 EST
What is the status for Fedora 12 for this issue?
Comment 34 Bill Nottingham 2009-12-06 12:07:18 EST
It was fixed a long time ago during Fedora 12 development. See comment #24.
Comment 35 udo 2009-12-06 12:29:35 EST
Thanks, will pay extra attention during next reboot.
Comment 36 Fedora Update System 2009-12-07 02:24:32 EST
initscripts-8.95.1-1 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update initscripts'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-12765
Comment 37 Fedora Update System 2009-12-21 23:49:44 EST
initscripts-8.95.1-1 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

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