24.12.2015 03:48, Alex Crawford пишет: > On 12/23, Jóhann B. Guðmundsson wrote: >> The usual underlying cause of usage of Environment or EnvironmentFile in >> type units is more or less always due to the fact that the >> daemon/service cannot read configuration file on startup thus the answer >> is you would use a daemon that was written in a such manner it could >> read configuration file, generate that file and get rid of the extra >> administrator step of having administrators create and use drop-in's or >> am I missing something? > > We are effectively using the drop-in to allow the user to map command line > options to dynamic data. Since the user won't know things like IP addresses, > they cannot write a traditional configuration file: > > $ cat static.conf > IP=1.2.3.4 > > They would instead have to write something like this: > > $ cat dynamic.conf > IP=COREOS_PUBLIC_IPV4 >
I do not follow. You said that you are using separate service to generate file that contains correct IP=1.2.3.4 How does it matter whether this file is now read by systemd or your daemon directly? > Of course, the daemon would then need to understand how to follow this mapping > and do the substitution itself. We instead decided to piggy-back on systemd > and > let it do the mapping for us. > But systemd does not do any mapping - it simply passes along result of mapping which another program has done. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
