Bug #5297

Locale fails on a SuSE system

Added by Oliver Eichler almost 4 years ago. Updated over 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Commit Number:
Affected Version:


The used system is a minimal server with SuSE Leap 42.2 installed. I use RhodeCode-installer-linux-build20170418_2200 to install.

The VCSServer failes to start. See attached server log.

The root cause seems to be a failing "locale.setlocale(locale.LC_ALL, u'')".

On the server I get for locale:


If I use the server's python environment I can do:

import locale
locale.setlocale(locale.LC_ALL, u'')

As a result I get "en_US.UTF-8"

If I use the python environment from RhodeCode by:

rccontrol ishell comunnity-1

The code snippet will fail with the same error message as in the log.

Probably the python environment shipped with RhodeCode is expecting a different locale setup than what's done in SuSE.


vcsserver.log (505 KB) vcsserver.log Oliver Eichler, 28.04.2017 17:24

Updated by Nikolay Yankin about 3 years ago

Same problem for me.


Updated by Marcin Kuzminski [CTO] about 3 years ago

from the ticket

Setting LOCALE_ARCHIVE=/usr/lib64/locale/locale-archive in .rccontrol/supervisor/supervisord.ini fixes the problem

it's an enviroment= option


Updated by Marcin Kuzminski [CTO] almost 3 years ago

  • Target version changed from v4.7 to v4.13

Updated by Boris Basic over 2 years ago

Same problem after upgrading from Ubuntu 16.10 to 18.04 LTS. I tried setting LOCALE_ARCHIVE and LC_ALL in supervisord.ini but it did not fix the problem.

The only solution in my case was to comment out line 30 in /opt/rhodecode/store/hgp03jrdni84hg60af1pw36swfwq3rm4-python2.7-mercurial-4.4.2/lib/python2. 7/site-packages/mercurial/


Updated by Marcin Kuzminski [CTO] over 2 years ago

Did you restart whole supervisord?

We thought this is fully fixed now


Updated by Boris Basic over 2 years ago

Yes, I also restarted the whole system, same issue each time. The only solution was to disabled the failing command.


Updated by Marcin Kuzminski [CTO] over 2 years ago

Would it be possible to have a remote session with your system so someone from our team can look at this?


Updated by Boris Basic over 2 years ago

Of course, I'll give you access tomorrow if you are available.


Updated by Marcin Kuzminski [CTO] over 2 years ago

That's great we'll poke around, hopefully, we can find some better solution. You can write to with credentials, as those are private tickets that we can only see.

Thanks again!


Updated by Boris Basic over 2 years ago

Thanks, I sent the credentials by mail, you can access the server to look art the issue.


Updated by Marcin Kuzminski [CTO] over 2 years ago

We've identified the problem for now. It looks like since glibc 2.27 the generated locale broke backward compatibility. We've yet not found a solution to this problem, the only thing right now is to potentially either re-generate the locale-archives using older glibc or downgrade glibc to pre 2.27


Updated by Marcin Kuzminski [CTO] over 2 years ago

Another way to fix this:

Fedora 23 / Ubuntu 18.04

|RCC| has a know problem with locales, due to changes in glibc 2.27+ which affects
the local-archive format, which is now incompatible with our used glibc 2.26.

To work around this problem, you need set path to ``$LOCAL_ARCHIVE`` to the
locale package in older pre glibc 2.27 format, or set `LC_ALL=C` in your enviroment.

To use the pre 2.27 locale-archive fix follow these steps:

1. Download the pre 2.27 locale-archive package

.. code-block:: bash


2. Point ``$LOCAL_ARCHIVE`` to the locale package.

.. code-block:: bash

    $ export LOCALE_ARCHIVE=/home/USER/locale-archive  # change to your path

Updated by Daniel D over 2 years ago

  • Status changed from New to In Progress

Updated by Daniel D over 2 years ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF