时代变了，所以做最好的做法。

目前最好的方法是运行systemctl edit myservice ，它会为你创build一个覆盖文件，或者让你编辑一个现有的文件。

在正常的安装中，这将创build一个目录/etc/systemd/system/myservice.service.d ，并在该目录内创build一个名称以.conf结尾的文件（通常是override.conf ），在这个文件中，你可以添加或者覆盖发行版本中的任何部分。

例如，在文件/etc/systemd/system/myservice.service.d/myenv.conf ：

 [Service] Environment="SECRET=pGNqduRFkB4K9C2vijOmUDa2kPtUhArN" Environment="ANOTHER_SECRET=JP8YLOc2bsNlrGuD6LVTq7L36obpjzxd" 

另外请注意，如果目录存在且为空，则您的服务将被禁用！ 如果你不打算把东西放在目录中，确保它不存在。

作为参考，旧的方式是：

build议这样做的方法是创build一个包含variables的文件/etc/sysconfig/myservice ，然后使用EnvironmentFile加载它们。

有关完整的详细信息，请参阅Fedora有关如何编写systemd脚本的文档。

答案取决于variables是否应该是常量（即，不应该由用户获取单位来修改）还是variables（应该由用户设置）。

既然是你们当地的单位，那么边界就很模糊，任何一种方式都行得通。 但是，如果您开始分发它，它将会在/usr/lib/systemd/system ，这将变得非常重要。

不变的价值

如果这个值不需要改变每个实例，首选的方法是直接在单元文件中将它放在Environment=中：

 [Unit] Description=My Daemon [Service] Environment="FOO=bar baz" ExecStart=/bin/myforegroundcmd [Install] WantedBy=multi-user.target 

这样做的好处是variables和单元一起保存在单个文件中。 因此，单位文件更容易在系统之间移动。

variables值

但是，当系统pipe理员应该在本地更改环境variables的值时，以上解决scheme无法正常工作。 更具体地说，每当单元文件被更新时，需要设置新的值。

对于这种情况，将使用额外的文件。 如何 – 通常取决于分销政策。

一个特别有趣的解决scheme是使用/etc/systemd/system/myservice.service.d目录。 与其他解决scheme不同的是，该目录由systemd本身支持，因此没有configuration特定的path。

在这种情况下，您需要放置像/etc/systemd/system/myservice.service.d/local.conf这样的/etc/systemd/system/myservice.service.d/local.conf ，以添加单元文件的缺失部分：

 [Service] Environment="FOO=bar baz" 

之后，systemd在启动服务时合并这两个文件（在更改其中的任何一个之后，请记住systemd daemon-reload ）。 由于这个path是由systemd直接使用的，所以你不要使用EnvironmentFile= 。

如果仅在某些受影响的系统上更改该值，则可以将两个解决scheme组合在一起，直接在单元中提供默认值，并在另一个文件中提供本地覆盖。

http://0pointer.de/public/systemd-man/systemd.exec.html#Environment= – 你有两个select（Michael已经指出）：

 Environment= 

和

 EnvironmentFile= 

迈克尔给了一个干净的解决scheme，但我想从脚本得到更新的envvariables。 不幸的是，在systemd单元文件中不能执行bash命令。 幸运的是，你可以在ExecStart里触发bash：

http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=systemd.service&ampsect=5

请注意，此设置不直接支持shell命令行。 如果要使用shell命令行，则需要将其明确传递给某种shell实现。

我们的例子是：

 [Service] ExecStart=/bin/bash -c "ENV=`script`; /bin/myforegroundcmd"