Re: [systemd-devel] service.d/.conf files and multi-valued options
Am 2015-01-23 14:27, schrieb Lennart Poettering: Yes, it does, although only in the general systemd.unit(5), not in the specific options, so maybe it's not that easy to find. Actually, it kinda says it in the specific options. From the explanation of ExecStart=: ...If the empty string is assigned to this option, the list of commands to start is reset, prior assignments of this option will have no effect... Oh, I didn't see that while skimming the man page. Still, I think a tutorial manpage as I described (different ways to override distro configuration) would be a good idea. Would you accept a patch for something like that? If so, what should the man page be called? And at the explanation of ExecStartPre= says the syntax is identical to ExecStart=. So I think we are covered here. No, sure, I don't think ExecStartPre= needs additional information, I just didn't see the sentence in ExecStart=, sorry about that. Btw. it would also be nice to have a possibility to just remove a specific entry from a list, not to reset it completely. Probably less for things like Exec*=, but more for After=/Before=/... For example, if there's a unit with After=b.service c.service und as an admin I want to not order it after c.service, I will have to first reset the list (empty After=) and then add all the current other units it orders after again. If an update then makes the unit also be ordered after d.service to fix some other bug, the local setting will override the After=d.service too... Maybe something like 'After-=c.service'? Although that would probably break traditional ini parsers trying to process unit files... I'd be very careful with coming up with more and more syntaxes like this. People have also requested +=, to append things to existing lines. I agree that I also don't like that syntax, but: I think for simplicity's sake the right approach to remove parts of a unit file is to copy it from /usr to /etc, and then modify it there. .d/ is not the answer to everything. I am aware of course that copying the files from /usr to /etc will also disconnect you from new unit files added by package updates, but I guess you cannot have a cake and eat it too... But if I want to add something to After=/Before=/..., I can easily do that with a drop-in just containing After=foo.service. And that's indeed very useful, I've used that a couple of times. So for symmetry reasons, I think the converse would also be quite useful (although I haven't needed it that often). I don't have a good idea for the syntax just now, but would you be opposed to at least adding 'design a syntax for this' to the TODO list? Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service.d/.conf files and multi-valued options
Am 2015-01-23 12:21, schrieb Matthias Urlichs: Igor Bukanov: It is not clear from the systemd.unit manual page what happens when foo.service.d/bar.conf sets an option like Service/ExecStartPre that can be specified multiple times. From experimenting I see that *.conf files supply additional values to the option and to overwrite or remove already given values for the option one have to copy the whole file into /etc and edit it there. Is it so? Doesn't the manpage state that an empty entry clears the list? Yes, it does, although only in the general systemd.unit(5), not in the specific options, so maybe it's not that easy to find. I think it would be nice to have some kind of man page that is a tutorial as to what are the best practices to override distro service files with your own site-specific configuration, which also includes a couple of simple examples that cover the most common cases. Btw. it would also be nice to have a possibility to just remove a specific entry from a list, not to reset it completely. Probably less for things like Exec*=, but more for After=/Before=/... For example, if there's a unit with After=b.service c.service und as an admin I want to not order it after c.service, I will have to first reset the list (empty After=) and then add all the current other units it orders after again. If an update then makes the unit also be ordered after d.service to fix some other bug, the local setting will override the After=d.service too... Maybe something like 'After-=c.service'? Although that would probably break traditional ini parsers trying to process unit files... Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service.d/.conf files and multi-valued options
On Fri, 23.01.15 14:15, Christian Seiler (christ...@iwakd.de) wrote: Am 2015-01-23 12:21, schrieb Matthias Urlichs: Igor Bukanov: It is not clear from the systemd.unit manual page what happens when foo.service.d/bar.conf sets an option like Service/ExecStartPre that can be specified multiple times. From experimenting I see that *.conf files supply additional values to the option and to overwrite or remove already given values for the option one have to copy the whole file into /etc and edit it there. Is it so? Doesn't the manpage state that an empty entry clears the list? Yes, it does, although only in the general systemd.unit(5), not in the specific options, so maybe it's not that easy to find. Actually, it kinda says it in the specific options. From the explanation of ExecStart=: ...If the empty string is assigned to this option, the list of commands to start is reset, prior assignments of this option will have no effect... And at the explanation of ExecStartPre= says the syntax is identical to ExecStart=. So I think we are covered here. I mean, we could certainly duplicate the discussion of ExecStart= at ExecStartPre=, but I think it's nicer to just reference it again. Btw. it would also be nice to have a possibility to just remove a specific entry from a list, not to reset it completely. Probably less for things like Exec*=, but more for After=/Before=/... For example, if there's a unit with After=b.service c.service und as an admin I want to not order it after c.service, I will have to first reset the list (empty After=) and then add all the current other units it orders after again. If an update then makes the unit also be ordered after d.service to fix some other bug, the local setting will override the After=d.service too... Maybe something like 'After-=c.service'? Although that would probably break traditional ini parsers trying to process unit files... I'd be very careful with coming up with more and more syntaxes like this. People have also requested +=, to append things to existing lines. I think for simplicity's sake the right approach to remove parts of a unit file is to copy it from /usr to /etc, and then modify it there. .d/ is not the answer to everything. I am aware of course that copying the files from /usr to /etc will also disconnect you from new unit files added by package updates, but I guess you cannot have a cake and eat it too... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service.d/.conf files and multi-valued options
On Fri, 23.01.15 14:57, Christian Seiler (christ...@iwakd.de) wrote: Am 2015-01-23 14:27, schrieb Lennart Poettering: Yes, it does, although only in the general systemd.unit(5), not in the specific options, so maybe it's not that easy to find. Actually, it kinda says it in the specific options. From the explanation of ExecStart=: ...If the empty string is assigned to this option, the list of commands to start is reset, prior assignments of this option will have no effect... Oh, I didn't see that while skimming the man page. Still, I think a tutorial manpage as I described (different ways to override distro configuration) would be a good idea. Would you accept a patch for something like that? If so, what should the man page be called? Sure, we can always use more man pages! Maybe simply call it systemd.turorial or so, which could then get sections explainaining how to best write new unit files, how to override/extend vendor unit files, and so on. I think for simplicity's sake the right approach to remove parts of a unit file is to copy it from /usr to /etc, and then modify it there. .d/ is not the answer to everything. I am aware of course that copying the files from /usr to /etc will also disconnect you from new unit files added by package updates, but I guess you cannot have a cake and eat it too... But if I want to add something to After=/Before=/..., I can easily do that with a drop-in just containing After=foo.service. And that's indeed very useful, I've used that a couple of times. So for symmetry reasons, I think the converse would also be quite useful (although I haven't needed it that often). I don't have a good idea for the syntax just now, but would you be opposed to at least adding 'design a syntax for this' to the TODO list? It's not just the syntax I am concerned about. It's more about overloading the language with too many features. It's supposed to be easy to parse, just a bunch of assigments. In fact the assignment of the empty string to reset lists is already a bit in the territory of this might be too complex... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service.d/.conf files and multi-valued options
Hi, Dimitri John Ledkov: foo.service.d/bar.conf sets an option like Service/ExecStartPre that can be specified multiple times. Doesn't the manpage state that an empty entry clears the list? A snippet: [Unit] Wants= Does not remove want dependencies declared in the unit section in the unit file under /usr. Meh. Obviously that works only for some unit file entries, not for others. Time to impart more consistency? -- -- Matthias Urlichs signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service.d/.conf files and multi-valued options
On 23 January 2015 at 11:21, Matthias Urlichs matth...@urlichs.de wrote: Hi, Igor Bukanov: It is not clear from the systemd.unit manual page what happens when foo.service.d/bar.conf sets an option like Service/ExecStartPre that can be specified multiple times. From experimenting I see that *.conf files supply additional values to the option and to overwrite or remove already given values for the option one have to copy the whole file into /etc and edit it there. Is it so? Doesn't the manpage state that an empty entry clears the list? A snippet: [Unit] Wants= Does not remove want dependencies declared in the unit section in the unit file under /usr. /me continues my unwants ramblings. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service.d/.conf files and multi-valued options
On Fri, Jan 23, 2015 at 03:12:11PM +0100, Lennart Poettering wrote:
On Fri, 23.01.15 14:57, Christian Seiler (christ...@iwakd.de) wrote:
Am 2015-01-23 14:27, schrieb Lennart Poettering:
Yes, it does, although only in the general systemd.unit(5), not in the
specific options, so maybe it's not that easy to find.
Actually, it kinda says it in the specific options. From the
explanation of ExecStart=:
...If the empty string is assigned to this option, the list of
commands to start is reset, prior assignments of this option will have
no effect...
Oh, I didn't see that while skimming the man page. Still, I think a
tutorial manpage as I described (different ways to override distro
configuration) would be a good idea. Would you accept a patch for
something like that? If so, what should the man page be called?
Sure, we can always use more man pages! Maybe simply call it
systemd.turorial or so, which could then get sections explainaining
how to best write new unit files, how to override/extend vendor unit
files, and so on.
I think it might be better to stick it into systemd.unit. There's really
no reason not to, and this way it'll have more exposure. People are more
likely to miss a separate page.
I think it would be great to have an Examples section in systemd.{unit,
service,socket,path,...} giving a semi-realistic example of a unit that
can serve as a template. For systemd.socket there should be two: an
Accept=yes and Accept=no.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
