[systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths

[Josh Triplett]

On Mon, Oct 20, 2014 at 08:48:01PM +0200, Lennart Poettering wrote:
> On Mon, 20.10.14 11:28, josh at joshtriplett.org (josh at joshtriplett.org) wrote:
> > > I'd really prefer if we'd keep things in logind.conf and just provide
> > > the option of using logind.conf.d. This would be similar to unit
> > > files, where the unit files are where the beef is and .d/ is just a
> > > way to override/extend is. THe man page of logind.conf should
> > > reference the ability that .d/ files are supported, but that should be
> > > it for the documentation. We should really try to not to be too
> > > surprising here for admins which tend to expect one configuration
> > > file, not many.
> > 
> > The main awkwardness there is that /etc/logind.conf, as a file in /etc,
> > should be parsed *after* /usr/lib/systemd/logind.conf.d/ and *before*
> > /etc/systemd/logind.conf.d/ , which breaks the usual logic to load all
> > files in order with files in /etc overriding files in /usr.
> 
> Well, as for units the main file should be read first (taking the
> /usr+/etc override logic into account), and only then we should read
> the .d/ drop-ins (individually following the /usr+/etc override
> logic). THis is what we do for unit files too.
> 
> .d/ in this context really are supposed to be for overrding and
> extending, and hence reading the .d/ snippets in /usr after the main
> confi file from /etc is the right thing to do I believe.
> 
> Ultimately the difference really shouldn#t matter too much I
> think. After all the version in /usr is for vendor defaults, and the
> stuff in /etc for user overrides. .d/ are for overrding hence mostly
> make sense in /etc only really, and should be the total exception in
> /usr.

OK, if you're fine with /usr/lib/systemd/logind.conf.d/*.conf overriding
/etc/logind.conf, then the patch gets *really* simple, and I'll submit
v3 soon.

- Josh Triplett