Re: [systemd-devel] Per-instance override with foobar.service.d
On 18/04/13 01:27, Lennart Poettering wrote: 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? yes - agree - foobar@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, 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... 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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Per-instance override with foobar.service.d
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
Re: [systemd-devel] Per-instance override with foobar.service.d
On 12/04/13 14:00, Zbigniew Jędrzejewski-Szmek wrote: foobar@.service and foobar@.service.d/myinstance.conf foobar@.service and foobar@myinstance.service.d/myinstance.conf This would be possible, if somebody implements it. 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 The idea is that different sources (rpms, administrator, whatever) provide snippets that are then merged. So there's no central registration of snippet names, and the namespace cannot be reused for instances. What about this though? foobar@myfirstinstance.service.d/... foobar@mysecondinstance.service./... where the relevant .conf would be selected based on the instance name. 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) There can be multiple files. Sure there can be multiple files, but I did suggest this as an alternative when there is only one file. I'm finding that I have lots of examples where I have a directory containing one file and it seems like an unnecessary complexity in that scenario. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Per-instance override with foobar.service.d
foobar@.service and foobar@.service.d/myinstance.conf foobar@.service and foobar@myinstance.service.d/myinstance.conf This would be possible, if somebody implements it. 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 The idea is that different sources (rpms, administrator, whatever) provide snippets that are then merged. So there's no central registration of snippet names, and the namespace cannot be reused for instances. where the relevant .conf would be selected based on the instance name. 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) There can be multiple files. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Per-instance override with foobar.service.d
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 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. 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) ? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
