<div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>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 <i>during</i> boot.<br><br>Then I ran across this little snippet in the man page for systemd.generator, which seems to imply the opposite:<br><span style="color:rgb(0,0,0);font-family:"Times New Roman"">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.</span><br><br>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/)<br clear="all"><div>Put differently, is a drop in considered to be a unit file or to be configuration (for the purposes of the above helptext)?<br><br>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?<br><br>Thanks!</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">~Sean McKay<br></div></div></div>