Hide Forgot
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.
+ fsadm is affected as well as this script parses output and it expects the messages to be in one predefined language.
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").
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.
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