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

[Kay Sievers]

On Wed, Jul 2, 2014 at 3:05 AM, 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.

We don't want timestamp magic here. We don't do that anywhere and
should not start things like that. Order should be defined simply by
the location, not by timestamps.

> 2. make localectl generate a warning if anything is set on the commandline,
> that those settings will take precedence after reboot.
>
> This will keep the possibility to use dynamic configuration, and give
> the admin a hint and a chance to update or clean up the commandline.
>
> 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.

That is right, but we still should not introduce any such magic.

Putting things on the kernel command line should be a rare exception,
it should be completely empty in the usual case, and it should not
involve any complicated evaluation and comparison ordering rules what
might be older or newer.

Kay

Kay