[systemd-devel] Per-instance override with foobar.service.d

[Lennart Poettering]

On Mon, 08.04.13 20:08, John Lane (systemd at jelmail.com) wrote:

> I'm trying out the new foobar.service.d way of overriding unit files.
> 
> I thought that I'd be able to have a number of service instances
> that were overridden differently but that does not seem to be the
> case (or, at least, I can't get it to work).
> 
> I first updated to systemd 200 and tried foobar.service.d with
> foobar.service.d/custom.conf; this works as described on the man
> page and release notes.
> 
> I've also tried:
> 
> foobar at .service and foobar at .service.d/myinstance.conf
> foobar at .service and foobar at myinstance.service.d/myinstance.conf

This should definitely work, and if it doesn't this sounds like
oversight. I have added to the TODO list to fix this.

> which don't work so I guess this isn't implemented. If so, would
> something like that be a reasonable request to be considered ?
> 
> I was thinking...
> foobar at .service
> foobar at .service.d/myfirstinstance.conf
> foobar at .service.d/mysecondinstance.conf
> 
> where the relevant .conf would be selected based on the instance name.

This sounds redundant and confusing, no? I mean, if we'd implement that
you only could have exctly one drop-in file pre instance, and that wold
be a serious limitation, no?

> I was also wondering why the need for a separate sub-directory when
> there's only one file inside it. Could a file like
> "foobar.service.conf" be considered as an alternative  (and,
> perhaps, foobar at myinstance.service.conf) ?

I'd prefer not adding to much redundancy here. Also, the .d/ scheme for
multiple drop-ins is also kinda known vocabulary on Unix already, so we
thought to stick to it, and have things a bit uniform...

I mean, I can be conviced to add something if it really makes sense. But
for that it better not add redundancy, or if it does then you need a
really strong case for it...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.