On Wed, 23.12.15 11:30, Alex Crawford (alex.crawf...@coreos.com) wrote: > On 12/23, Lennart Poettering wrote: > > On Wed, 23.12.15 06:01, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > > > What usescases do you see for it's existence. > > > > Well, the usecase that this is what's out there right now, and we have > > to stay compatible. It's not precisely an exotic feature, we can > > easily deprecated. It's unfortunately pretty popular. > > We use it within CoreOS to allow the user to inject dynamic data into the > service. For example, you may have a service like this: > > $ cat etcd.service > [Unit] > Requires=metadata.service > After=metadata.service > > [Service] > EnvironmentFile=/run/coreos/metadata > ExecStart=/usr/bin/etcd --public-ip=${COREOS_PRIVATE_IPV4} > > where "metadata.service" populates /run/coreos/metadata with a bunch of info > about the system (like Facter from puppet). The user can then pick and choose > the appropriate variables to use (maybe they need the public address instead) > and override the ExecStart in a drop-in. > > I like this model and I'm not sure how I would solve this if EnvironmentFile > didn't exist.
I see no reason why systemd should be involved with this. Just make etcd a proper daemon, and read its config data directly, rather then serializing it into the command line. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel