Bug 1085832 - snapper fails if not installed locale is set
snapper fails if not installed locale is set
Status: RESOLVED FIXED
: 1081372 (view as bug list)
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kubic
Current
x86-64 openSUSE Factory
: P2 - High : Normal (vote)
: ---
Assigned To: YaST Team
E-mail List
https://trello.com/c/RYVaFyPX/2185-op...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-19 13:19 UTC by Ignaz Forster
Modified: 2018-04-27 14:27 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Error message 1 (15.65 KB, image/png)
2018-03-19 13:19 UTC, Ignaz Forster
Details
Error message 2 (9.70 KB, image/png)
2018-03-19 13:20 UTC, Ignaz Forster
Details
Yast log (166.58 KB, application/x-xz)
2018-03-19 13:33 UTC, Ignaz Forster
Details
login on SLE15 with borken locale settings (14.44 KB, image/png)
2018-04-03 10:00 UTC, Arvin Schnell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ignaz Forster 2018-03-19 13:19:29 UTC
Created attachment 764095 [details]
Error message 1

Selecting a different language then "English (US)" in the installation overview screen will result in two snapper error messages during finalization of the installation (see attachments). The system's locale is still English (en_US.UTF-8) in the installed system.
Comment 1 Ignaz Forster 2018-03-19 13:20:12 UTC
Created attachment 764096 [details]
Error message 2
Comment 2 Ignaz Forster 2018-03-19 13:33:12 UTC
Created attachment 764099 [details]
Yast log
Comment 3 Thorsten Kukuk 2018-03-20 08:47:54 UTC
For YaST we have already a bug report.

Arvin, is there a reason why all tools/daemons in the snapper package ignore if setlocale fails, but only snapper fails with a hard error?

This doesn't make much sense to me, and I fail to see why snapper needs to exit instead of printing only a warning and continues?

The situation, that the locale is wrong happens quite often to me (thanks to ssh ...).
Comment 4 Arvin Schnell 2018-03-20 09:00:15 UTC
(In reply to Thorsten Kukuk from comment #3)

> Arvin, is there a reason why all tools/daemons in the snapper package ignore
> if setlocale fails, but only snapper fails with a hard error?

Yes, snapper it the only program with propoer internationalization.
Comment 5 Richard Brown 2018-03-30 21:13:41 UTC
This bug is still present in snapshot 0329 and blocks all SUSE CaaSP & Kubic installations with any language besides English US

Raising the Priority accordingly
Comment 6 Arvin Schnell 2018-04-03 08:58:53 UTC
What is the use case of setting up a system in a language and not installing
the locale data required for that language?

For me this issue is still not valid.
Comment 7 Richard Brown 2018-04-03 09:10:32 UTC
(In reply to Arvin Schnell from comment #6)
> What is the use case of setting up a system in a language and not installing
> the locale data required for that language?
> 
> For me this issue is still not valid.

It was a PM requirement for SUSE CaaSP (and as a result, Kubic also)

Because of their role as a hands-off, management free host, no Kubic host should have any locale data present. They shouldn't be needed, because no user should ever be connecting to the system.

Localisation should be present in Velum (the webui for the cluster), and YaST (during the installation)

This is the bug - snappers assumption that because they needed localisation during the installation they will have it in the resulting system means that snapper breaks on installation, as reported in comment #0

I have discussed this with Thorsten for what feels like the nth time today. There is apparently no room for maneuver here - we cannot have CaaSP and Kubic install all locale data.

Thorsten has also discussed this with Jiri

We need Snapper to be installable and working without locale data, even if the initial installation used a custom locale.

Or to put it another way
"Fix your system" is a 100% incorrect error message; "the system" is fine and working as designed.
Comment 8 Arvin Schnell 2018-04-03 09:19:46 UTC
(In reply to Richard Brown from comment #7)

> This is the bug - snappers assumption that because they needed localisation
> during the installation they will have it in the resulting system means that
> snapper breaks on installation, as reported in comment #0

The "assumption" of snapper is that 'locale::global(locale(""));' works.
Nothing else. And almost all programs make that call.

> We need Snapper to be installable and working without locale data, even if
> the initial installation used a custom locale.

The proper solution is to not set the locale in the installed system. But
proper solutions and common sense are absent quite often here.
 
> Or to put it another way
> "Fix your system" is a 100% incorrect error message; "the system" is fine
> and working as designed.

No, the system is broken!
Comment 9 Richard Brown 2018-04-03 09:24:54 UTC
(In reply to Arvin Schnell from comment #8)
> 
> The "assumption" of snapper is that 'locale::global(locale(""));' works.
> Nothing else. And almost all programs make that call.

> > Or to put it another way
> > "Fix your system" is a 100% incorrect error message; "the system" is fine
> > and working as designed.
> 
> No, the system is broken!

Then please explain how the following applications all install, configure, and work perfectly fine without a warning like snappers (frankly rude) "Fix your system"

zypper
yast
docker
kubectl
hyperkube

and many, many more

Your assertion that snapper's behaviour is fair and correct doesn't seem to hold water when "almost all programs" are considered.
Comment 10 Arvin Schnell 2018-04-03 09:30:44 UTC
Do those programs work as expected (e.g. showing localized messages)?
Comment 11 Richard Brown 2018-04-03 09:37:16 UTC
(In reply to Arvin Schnell from comment #10)
> Do those programs work as expected (e.g. showing localized messages)?

They work as expected - showing messages in a locale which is available.

Unlike snapper they do not prevent themselves from working unnecessarily nor insult the user or their system.
Comment 12 Thorsten Kukuk 2018-04-03 09:55:22 UTC
(In reply to Arvin Schnell from comment #10)
> Do those programs work as expected (e.g. showing localized messages)?

No, they don't show translations, since for the functionality of this applications, localisation is not required. So they still continue to work.

(In reply to Arvin Schnell from comment #8)

> No, the system is broken!

No, the system is not broken at all. If, then the system users locale is unsupported. 
As already written, use the following example to show that the current snapper behavior is wrong:

Use a system with german locale.
ssh to a system without german locale.
locale will show you de_DE.UTF-8 as language, but that is not installed.
zypper continues to work fine.
All other tools I tried continues to work fine.
Of course all above tools will use english as locale, but they still work without error message.
But snapper tells me that the system is broken and refuses to work.
Comment 13 Arvin Schnell 2018-04-03 09:59:52 UTC
(In reply to Richard Brown from comment #11)

> They work as expected - showing messages in a locale which is available.

For me that classifies as not working as expected.

And you also like a bunch of warnings during login.
Comment 14 Arvin Schnell 2018-04-03 10:00:20 UTC
Created attachment 765747 [details]
login on SLE15 with borken locale settings
Comment 15 Arvin Schnell 2018-04-03 10:01:33 UTC
(In reply to Thorsten Kukuk from comment #12)

> As already written, use the following example to show that the current
> snapper behavior is wrong:
> 
> Use a system with german locale.
> ssh to a system without german locale.
> locale will show you de_DE.UTF-8 as language, but that is not installed.
> zypper continues to work fine.
> All other tools I tried continues to work fine.
> Of course all above tools will use english as locale, but they still work
> without error message.
> But snapper tells me that the system is broken and refuses to work.

The login scripts should check the locale.
Comment 16 Thorsten Kukuk 2018-04-03 10:14:21 UTC
(In reply to Arvin Schnell from comment #14)
> Created attachment 765747 [details]
> login on SLE15 with borken locale settings

Lot of warnings, no error.
Can you login? YES!
Can you call snapper: NO!

Any more questions which behavior is broken?
Comment 17 Arvin Schnell 2018-04-03 10:28:08 UTC
So the system is fine if the user gets such a bunch of messages during
login. That is indeed remarkable.

And I never had question concerning what is broken.
Comment 18 Swamp Workflow Management 2018-04-04 12:20:09 UTC
This is an autogenerated message for OBS integration:
This bug (1085832) was mentioned in
https://build.opensuse.org/request/show/593527 Factory / patterns-caasp
Comment 19 Lukas Ocilka 2018-04-10 11:53:16 UTC
We have to look at the problem pragmatically:

Should "broken" locale settings stop you from doing anything with your system?
If so, and hacker breaks locale (let's say it's the only way she can do now),
should firewall stop working? If I break my locale settings by mistake and
log out, should I be able to log in and fix it?

What if I change my locale (in a wrong way), reboot and then I want to rollback?
Should snapper crash then? Should snapper refuse to rollback?

Of course, developers often call `LANG=C do something`, e.g., https://superuser.com/questions/334800/lang-c-is-in-a-number-of-the-etc-init-d-scripts-what-does-lang-c-do-and-why

What is worse: If all is in English or if system refuses to boot and do
anything if locale "is wrong"?

My view is that we can complain, but then we need to fallback to safe default
and let the admin work with their system.
Comment 20 Martin Pluskal 2018-04-10 12:13:20 UTC
For the record there was issue with accidentally set locales - bsc#933241
Comment 21 Thorsten Kukuk 2018-04-13 11:02:03 UTC
(In reply to Martin Pluskal from comment #20)
> For the record there was issue with accidentally set locales - bsc#933241

That's solveable without crash or hard exit, see any other localized application we ship.
Comment 22 Arvin Schnell 2018-04-20 13:47:24 UTC
Softened error handling if setting locale failed. Have fun with distorted screens.

SR: https://build.opensuse.org/request/show/599314
Comment 23 Steffen Winterfeldt 2018-04-27 14:27:38 UTC
*** Bug 1081372 has been marked as a duplicate of this bug. ***