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

[John Lane]

On 18/04/13 01:27, Lennart Poettering wrote:
> 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?

yes - agree - foobar at myinstance.service.d/ is the better option for instance-specific configs and, if that's on the TODO list - great!

>> 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...
My thoughts were merely following on from what has gone before, like on 
Xorg where you can either have a single .conf or a .d containing 
multiple configs. I think requiring a .d when you know there is only 
going to be a single file is overkill but that's just personal preference.
>
> 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...
No really strong case here - just a suggestion.
> Lennart
>
Regards,
John