On 12/23/2015 07:30 PM, Alex Crawford wrote:
> 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.
This breaks reload.

But, of course, if etcd does not support reload, and it's planned that
one etcd node will fail to serve its clients while it is down /
restarting, then it's a fine use of EnvFile.

-- 
    Rudd-O
    http://rudd-o.com/


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to