On 18/04/13 01:27, Lennart Poettering wrote:
On Mon, 08.04.13 20:08, John Lane ([email protected]) 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:
[email protected] and [email protected]/myinstance.conf
[email protected] and [email protected]/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...
[email protected]
[email protected]/myfirstinstance.conf
[email protected]/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 - [email protected]/ 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, [email protected]) ?
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
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
