On Mon, 08.04.13 20:08, John Lane (syst...@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@.service and foobar@.service.d/myinstance.conf > foobar@.service and foobar@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@.service > foobar@.service.d/myfirstinstance.conf > foobar@.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, foo...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
