dash is empty, scopes are missing

[dinamic]

Ubuntu 16.10
dash is empty, scopes are missing

[Michał Sawicz (saviq)]

Is your scope registry running?

$ initctl status scope-registry

Can you post the log from it, too?

[dinamic (dinamic6661)]

$ initctl status scope-registry

scope-registry stop/waiting

[Paweł Stołowski (stolowski)]

Looks like it's crashing on invalid locale setup (boost throws exception on us); what is your locale (language) setup?

[dinamic (dinamic6661)]

$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LANGUAGE=en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=ro_RO.UTF-8
LC_TIME=ro_RO.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=ro_RO.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=ro_RO.UTF-8
LC_NAME=ro_RO.UTF-8
LC_ADDRESS=ro_RO.UTF-8
LC_TELEPHONE=ro_RO.UTF-8
LC_MEASUREMENT=ro_RO.UTF-8
LC_IDENTIFICATION=ro_RO.UTF-8
LC_ALL=

[dinamic (dinamic6661)]

hm.. i think i'm dumb... can anyone confirm?

so, i've tried to run locale-gen in terminal app but i kept seeing apparmor denials in kernel log. so switched to a VT and locale-gen.. and it worked.. after restart i can see the scopes. i think.. i've updated ubuntu from ubuntu terminal app.. and that messed things up?

[dinamic (dinamic6661)]

anyway.. it's still sort of a bug? i mean... the system shouldn't fail that hard with bad locales?

[Paweł Stołowski (stolowski)]

I agree this is a problem, it's an old bug and in fact you'll see a lot of reports about "locale::facet::_S_create_c_locale name not valid" exception thrown by boost - see e.g. the last comment here https://github.com/udoprog/c10t/issues/203

There is nothing we can do at the level it surfaces (scoperegistry in this case) as it aborts the creation of most basic objects we need, so we cannot just catch and ignore it.

This problem also manifests itself in unity8-dash (I'm sure it hit it too with your broken locale setup) and the best we could do there was to just prevent the restart-loop of unity8-dash (and leave the dash empty as we cannot instantiate scopes runtime with broken locale).

I'm really not sure what more we can do. Adding boost to the bug.

[Michi Henning (michihenning)]

The problem is caused by boost, and we are defenseless until we get 1.57 or later into the image. There is an earlier bug about this here: https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1303637

[Paweł Stołowski (stolowski)]

Hmm, Ubuntu 16.10 has boost 1.61. I agree we are defenseless, but are we sure it was fixed in boost?

[Michi Henning (michihenning)]

If this is with boost 1.61, either the problem is still present in boost or, if the local files were messed up somehow, the exception would legitimately be raised because the locale definition is broken.

Comment #9 seems to indicate that the problem was fixed after regenerating the locale. In that case, the exception is perfectly legitimate, and there is no bug at all. If the locale info is broken, we can't parse essential configuration files in scopes-api, which prevents the runtime from being started. In that case, all scopes are inaccessible, period.

If the problem indeed went away after regenerating the local info, there is no bug here. In that case, can you close as invalid please?

[James Henstridge (jamesh)]

Before anyone suggests it: while we do have a copy of Boost 1.58 in stable-phone-overlay, actually using it for libunity-scopes would be an ABI break if we have any scopes that link directly to boost libraries themselves (you'd get a little 1.55 and a little 1.58 in the same address space using the same symbol names).

In the survey I did in December, there were 6 scopes linking to a Boost library. Two of those were Javascript scopes, so I suspect the number would be much higher if I reran the checks today.