letsencrypt.service ：
[Unit] Description=Renews letsencrypt certificates After=network.target letsencrypt_concat_fullchain_privkey.service [Service] Type=oneshot WorkingDirectory=/etc/letsencrypt/ ExecStart=/usr/bin/letsencrypt renew
当我手动启动这个服务： sudo systemctl start letsencrypt它似乎并没有启动letsencrypt_concat_fullchain_privkey.service服务。 我已经运行sudo systemctl start letsencrypt_concat_fullchain_privkey.service ，它的工作原理应该如此。
我想要做的是，当letsencrypt.service完成，我想它启动letsencrypt_concat_fullchain_privkey.service服务。
After=并不意味着一个依赖关系（只有顺序），你可以build立依赖Requires=或Wants=指令。
需要=
configuration其他单元的需求依赖关系。 如果这个单位被激活，这里列出的单位也会被激活。 如果其他单位之一被取消激活或激活失败，则该单位将被停用。 该选项可以多次指定，也可以在一个选项中指定多个空格分隔的单位，在这种情况下，将创build所有列出名称的需求依赖关系。 请注意，需求相关性不会影响服务启动或停止的顺序。 这必须使用After=或Before=选项独立configuration。 如果一个单元foo.service需要一个configuration为Requires =的单元bar.service，并且没有configuration使用After=或者Before=顺序，那么如果foo.service被激活，那么这两个单元将同时启动并且没有任何延迟。 通常，为了在处理失败的服务时实现更健壮的系统，使用“Wants=而不是“Requires=是更好的select。请注意，这个依赖types并不意味着当这个单元运行时其他单元总是处于激活状态。 具体来说：失败的条件检查（如
ConditionPathExists=，ConditionPathExists=，… – 见下文）不会导致具有Requires=依赖关系的单元的启动任务失败。 此外，某些单元types可能会自行closures（例如，服务进程可能决定完全退出，或者设备可能会被用户拔出），而不会传播到具有Requires=dependency的单元。 使用BindsTo=依赖关系types和After=来确保一个单位可能永远不处于活动状态，没有一个特定的其他单位也处于活动状态（见下文）。请注意，这种types的依赖关系也可以在单元configuration文件之外进行configuration，方法是在伴随单元文件的
.requires/目录中添加符号链接。 有关详情，请参阅上文。想要=
Requires=较弱版本。 如果configuration单位是，则此选项中列出的单位将启动。 但是，如果上市单位不能启动或不能join交易，这对整个交易的有效性没有影响。 这是将一台设备启动挂钩到另一台设备启动的推荐方式。请注意，此types的依赖关系也可以在单元configuration文件之外进行configuration，方法是将符号链接添加到伴随单元文件的
.wants/目录中。 有关详情，请参阅上文。
参考： http : //freedesktop.org/software/systemd/man/systemd.unit.html
我想要做的是，当letsencrypt.service完成，我想它启动letsencrypt_concat_fullchain_privkey.service服务。
你想把它添加到你的letsencrypt.service文件中，然后：
ExecStartPost=/bin/systemctl start letsencrypt_concat_fullchain_privkey.service
然后这个命令将在ExecStart=给出的命令后连续运行。
你可以在man systemd.service阅读更多关于ExecStartPost= ，或者查看man systemd.service任何systemd指令。