[systemd-devel] [PATCH] localed: search locale settings on kernel cmdline first

[Lennart Poettering]

On Wed, 02.07.14 03:05, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> 
> On Tue, Jul 01, 2014 at 04:36:47PM +0200, Lennart Poettering wrote:
> > On Tue, 01.07.14 16:47, microcai (microcai at fedoraproject.org) wrote:
> > 
> > > > Maybe another option is to improve localectl on the client side to
> > > > simply warn the user if there's something on the kernel cmdline
> > > > specified? (this check should probably test this directly, bypassing
> > > > localed, and thus get skipped if localectl is used on a remote host).
> > > > 
> > > > i.e. just a simple warning if you type "localectl" that says: "Warning:
> > > > Locale configuration has been specified on the kernel command line,
> > > > overriding the system settings below." or so...
> > > 
> > > kernel has BOOT time, etc settings has modified time, which one is newer, take 
> > > that ?
> > 
> > I am pretty sure we should stay with the simple logic of "kernel
> > cmdline overrides /etc". Trying to be smarter and saying newer /etc
> > overrides older /proc/cmdline will just be confusing, and has not been
> > used anywhere so far...
> One of the nice things about localectl set-locale was that it acted
> immediately. We should keep this property. So I think that the patch
> as is causes a usability regression, for things which are not started
> by systemd, and use /etc/locale.conf instead.
> 
> OTOH, the difference in behaviour between systemd and localed is annoying
> and potentially confusing.
> 
> I think we should
> 
> 1. make systemd and localed use the same logic, which follows the line
> proposed by microcai, so that a newer /etc/locale.conf wins over the
> commandline, which wins over an older /etc/locale.conf.

I am strongly against that. If people override settings via the kernel
command line, then that's the strongest way of overriding
configuration. It's the big big hammer, to make the system do what the
admin wants. It's something that should not happen in normal setups, and
we should never second-guess it. If people use the kernel cmdline, then
fuck yeah, we have to follow that.

That said localed is a frontend for configuring some files in /etc, and
it should be that. Yes, it is confusing, that the kernel cmdline
overrides whatever you change with localed, but well, that's completely
OK since the kernel cmdline is supposed to be that big big hammer, that
overrides everything.

Of course, it's a good idea to warn about this situation in localectl,
to make this less surprising, but I am absolutely positively sure that
we should not allow files to override explicit admin requests via the
kernel cmdline.

> I don't think that the argument that /proc/cmdline always wins is valid.
> For example root filesystem settings, logical volumes, the default unit,
> additional units to get started, filesystems to be mounted, are all things
> which are often dynamically altered at runtime. I don't think we should
> sacrifice usability for narrow consistency.

Yes, "rw" vs. "ro" is indeed an exception, and I have often wondered if
it should be, but it is the way it is since time began.

The thing is that I don't even believe that there's really a problem we
are trying to fix here. To me, the first question I'd ask if somebody
runs into this problem would always be: "So, why did you specify the
locale on the kernel cmdline in the first place?" -- making use of it
and assuming this was normal workflow is already wrong.

Lennart

-- 
Lennart Poettering, Red Hat