Bug #462

breakage when using non-US locales

Added by Stefan Praszalowicz over 10 years ago. Updated over 10 years ago.

Status:ClosedStart date:01/11/2011
Priority:NormalDue date:
Assignee:-% Done:


Category:Drivers - Auth
Target version:Release 2.2
Resolution:fixed Pull request:
Affected Versions:


When using the fr_FR locale on the frontend node, many things break due to unexpected script output.

Here's a quick list of issues I saw:
- "onehost list" shows 0 or even negative values for CPU fields and TMEM
- "onevm create" works but gets "Domaine" as the deploymend id, breaking vm monitoring and further lifecycle operation
- "onevm list" reports bad numbers (even after manually fixing the deployment id)

The fix for me was to use en_US on the front-end and compute nodes.

I'm also sorry to report that this problem was reported on the list in the past :p
- http://lists.opennebula.org/pipermail/users-opennebula.org/2010-February/001537.html
- http://lists.opennebula.org/pipermail/users-opennebula.org/2009-May/000446.html

I think the docs should be updated to mention this, at a minimum.
An extra step would be to add a warning (oned.log ?) if the locale isn't en_US.
A more risky approach would be to try and export LC_ALL=en_US somewhere that'd take care of all remote scripts.

Related issues

Duplicated by Bug #467: Set language to english before running commands Closed 01/14/2011

Associated revisions

Revision 1bb3a971
Added by Javi Fontan over 10 years ago

bug #462: set locales before executing commands in mads

Revision 9a566823
Added by Abel Coronado almost 4 years ago

Solved bug in capacity-create.js (#462)

Revision e887b582
Added by Abel Coronado almost 4 years ago

Solved bug in capacity-create.js (#462)

(cherry picked from commit 9a566823747649672ee9900f87fb832eb4075c86)


#1 Updated by Javi Fontan over 10 years ago

  • Category set to Drivers - Auth
  • Status changed from New to Closed
  • Target version set to Release 2.2
  • Resolution set to fixed

Also available in: Atom PDF