RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 902806 - Locales should be set with LC_ALL instead of LANG
Summary: Locales should be set with LC_ALL instead of LANG
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.4
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Zdenek Kabelac
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On: 889651
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-22 12:56 UTC by Peter Rajnoha
Modified: 2013-11-21 23:19 UTC (History)
13 users (show)

Fixed In Version: lvm2-2.02.100-1.el6
Doc Type: Bug Fix
Doc Text:
lvm2 dmeventd daemon tried to reset to C locales only through LANG environmental variable. However when system sets locales via LC_ALL it has higher priority and leads to huge memory consumptions. Problem is fixed by resetting LC_ALL to C instead of LANG.
Clone Of: 889651
Environment:
Last Closed: 2013-11-21 23:19:19 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1704 0 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2013-11-20 21:52:01 UTC

Description Peter Rajnoha 2013-01-22 12:56:46 UTC 
LVM2 should use LC_ALL instead of LANG variable throughout when defining the default "C" locale that is to be used to completely prevent locking any other locale into memory. Otherwise, this causes useless high memory usage as LVM makes use of memlock internally. This could be especially problematic when using dmeventd, clvmd and lvmetad that reside in memory as daemons.

The patch has already been committed upstream:
https://www.redhat.com/archives/lvm-devel/2013-January/msg00036.html


+++ This bug was initially created as a clone of Bug #889651 +++
--- Additional comment from Marian Csontos on 2013-01-17 14:54:46 CET ---

I just checked with recent nightly lvm2 build (2.02.98-8.21) and locale-archive were loaded.

--- Additional comment from Zdenek Kabelac on 2013-01-22 11:36:36 CET ---

dmeventd was reseting LANG variable to C locales - however system used LC_ vars to override them - thus locale archive got loaded.

Fixed upstream with this patch, that avoids locking archive in memory.

https://www.redhat.com/archives/lvm-devel/2013-January/msg00036.html

--- Additional comment from Marian Csontos on 2013-01-22 13:00:12 CET ---

Any chance getting this into 6.4?

Impact of the change is close to 0. Sanity only testing required.

Impact of the issue:
- in the worst case losing data when snapshot is not monitored and resized or lost mirror leg replaced.
- significant memory waste on low RAM systems (VMs)
- and last causing failures in our testing environment increasing noise/signal ratio and making it possible to miss a real bugs

Also after dmeventd failure, any watched devices are not re-registered until touched manually (either explicit registration or calling lvconvert) making the error span long lasting increasing potential to hit the issue.

This may be an issue behind the Bug 889361 - I have seen the segfault in the issue always being accompanied by this issue suggesting it may be low memory too.
Comment 1 Peter Rajnoha 2013-01-22 13:04:39 UTC 
+ fsadm is affected as well as this script parses output and it expects the messages to be in one predefined language.
Comment 2 Peter Rajnoha 2013-01-22 13:07:35 UTC 
Proposing this one as a blocker for inclusion in 6.4 Snapshot 5: as already commented above, the negative impact of this change is almost zero. However, the memory usage becomes much more optimal as there are no locales uselessly locked in memory (if set to a different language than "C").
Comment 3 Alasdair Kergon 2013-01-22 19:32:46 UTC 
1) If fsadm relies upon the output from a command being in a particular locale, it should be controlling that by setting the appropriate environment variables itself before running that command.  If it's not doing that, then it should be fixed.

2) What about systems that have deliberately chosen a different locale because they want system error messages in a different language?  LC_* overrides LANG, so this patch would remove support for configurations that are currently supported i.e. it could cause a regression.  I don't yet agree that the impact of this change would be "close to zero" as I think the analysis presented here is still incomplete.

3) The patch already committed upstream might need further modification before the next release.
Comment 9 errata-xmlrpc 2013-11-21 23:19:19 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1704.html
Note You need to log in before you can comment on or make changes to this bug.