Much obliged! -Sean From: Lennart Poettering On Mo, 22.02.21 23:22, Sean McKay (insanescientist@xxxxxxxxx) wrote: > Hi all, > > I've been looking to dynamically create .conf files at boot depending on > the hardware that I'm running on (to set MemoryMax, if it's relevant). I'd > assumed that the proper way to do this would be by using a generator, since > the .conf file won't automatically be loaded and would require triggering > the system manager to reload all configuration. And it didn't seem prudent > to call that *during* boot. > > Then I ran across this little snippet in the man page for > systemd.generator, which seems to imply the opposite: > Generators should only be used to generate unit files and symlinks to them, > not any other kind of configuration. Due to the lifecycle logic mentioned > above, generators are not a good fit to generate dynamic configuration for > other services. If you need to generate dynamic configuration for other > services, do so in normal services you order before the service in question. > > What I'm not clear on is whether this refers solely to configuration used > by the daemon itself (to use sshd as a well known example - eg: > /etc/ssh/sshd_config) or if it also refers to drop in .conf files (ie: > something in /run/systemd/system/ssh.service.d/) > Put differently, is a drop in considered to be a unit file or to be > configuration (for the purposes of the above helptext)? It's considered a unit file. I figure we should improve the docs on that, to make this clearer. > Would the recommended solution in this case be for me to use a generator to > create the relevant .conf file(s) for MemoryMax? Or would it be better to > use a normal service (with proper ordering against the ones it's modifying) > to generate those .conf files and call daemon-reload during boot? If the > latter, are there any expected risks associated with calling daemon-reload > during boot? Doing this with a generator sounds perfect to me. Lennart -- Lennart Poettering, Berlin |
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
