On Wed, 02.07.14 03:05, Zbigniew Jędrzejewski-Szmek (zbys...@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 (micro...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
