系统服务脚本路径：/usr/lib/systemd/system

创建.service后缀服务，例如fridayd.service

以下二进制服务配置参考：

以下java服务：

Type描述

参考：https://manpages.debian.org/bullseye/systemd/systemd.service.5.en.html

配置此服务单元的进程启动类型。一个simple，EXEC，forking，oneshot ， DBUS，notify 或idle ：

• 如果设置为simple（如果指定了ExecStart=但Type=和BusName=均未指定，则为默认值 ），服务管理器将认为该单元在主服务进程被分叉后立即启动。预计配置了ExecStart=的进程是服务的主要流程。在这种模式下，如果进程向系统上的其他进程提供功能，则应在服务启动之前安装其通信通道（例如由 systemd 设置的套接字，通过套接字激活），因为服务管理器将立即开始后续操作-up 单元，在创建主服务进程之后和执行服务的二进制文件之前。请注意，这意味着 即使服务的二进制文件无法成功调用（例如，因为选定的User=不存在，或者服务二进制文件丢失），简单服务的systemctl start命令行也会报告成功。

• exec类型类似于simple，但服务管理器会认为该单元在主服务二进制文件执行后立即启动。服务经理将延迟后续单位的启动，直到该时间点。 （或者换句话说：simple 在fork()返回后继续执行进一步的作业，而 exec在服务进程中的fork()和execve()都成功之前不会继续。）请注意，这意味着systemctl start 用于exec服务的命令行当服务的二进制文件无法成功调用时（例如因为选中的 User=不存在，或者服务二进制文件丢失）。

• 如果设置为forking，预计配置为ExecStart=的进程将调用fork()作为其启动的一部分。当启动完成并设置所有通信通道时，父进程将退出。子进程作为主服务进程继续运行，当父进程退出时服务管理器会认为该单元启动。这是传统 UNIX 服务的行为。如果使用此设置，建议也使用 PIDFile=选项，以便 systemd 能够可靠地识别服务的主进程。一旦父进程退出，systemd 将继续启动后续单元。

• oneshot 的行为类似于 simple；但是，服务管理器会在主进程退出后考虑启动单元。然后它将启动后续单元。 RemainAfterExit=对于这种类型的服务特别有用。 如果Type=和 ExecStart=均未指定，则Type= oneshot是隐含的默认值。请注意，如果在没有RemainAfterExit=的情况下使用此选项，则 服务将永远不会进入“活动”单元状态，而是直接从“激活”转换为“停用”或“死”，因为没有配置应连续运行的进程。RemainAfterExit=未设置）它不会显示为之后启动，而是显示为已死。

• dbus 的行为类似于 simple；但是，预计服务会在 D-Bus 总线上获得一个名称，如BusName=配置的那样。在获得 D-Bus 总线名称后，systemd 将继续启动后续单元。配置了这个选项的服务单元隐式地获得了对 dbus.socket 单元的依赖。如果BusName=，则此类型为默认类型被指定。这种类型的服务单元被认为处于激活状态，直到获得指定的总线名称。在使用总线名称时，它被视为已激活。一旦总线名称被释放，服务就被认为不再起作用，这具有服务管理器尝试终止属于该服务的任何剩余进程的效果。因此，将其总线名称作为其关闭逻辑的一部分删除的服务应准备好接收SIGTERM（或在KillSignal= 中配置的任何信号 ）作为结果。

• notify 的行为类似于 exec；但是，预计服务在完成启动时会通过sd_notify(3)或等效调用发送通知消息。发送此通知消息后，systemd 将继续启动后续单元。如果使用此选项，则 NotifyAccess=（见下文）应设置为打开对 systemd 提供的通知套接字的访问。如果NotifyAccess=丢失或设置为none，它将被强制设置为main。

• idle 的行为与simple非常相似 ；但是，服务程序的实际执行会延迟，直到所有活动作业都被调度。这可用于避免 shell 服务的输出与控制台上的状态输出交错。注意，这种类型只对提高控制台输出有用，不能作为通用的单元排序工具，而且这种服务类型的效果是有5s的超时，之后无论如何都会调用服务程序。

对于长时间运行的服务，通常建议尽可能使用Type= simple，因为它是最简单和最快的选项。但是，由于此服务类型不会传播服务启动失败，并且不允许针对服务初始化完成对其他单元进行排序（例如，如果客户端需要通过某种形式的 IPC 连接到服务，这很有用，并且 IPC 通道仅由服务本身建立 - 与通过套接字或总线激活或类似的方式提前执行此操作相反），对于许多情况来说可能还不够。如果有，请通知或dbus（后者仅在服务提供 D-Bus 接口的情况下）是首选选项，因为它们允许服务程序代码精确安排何时认为服务已成功启动以及何时继续执行后续单元。该通知服务类型需要在服务代码库的明确支持（如sd_notify（）或等效的API需要被服务在适当的时候调用） -如果它不支持，那么分叉是一种替代方案：它支持传统的UNIX服务启动协议。最后，执行对于足以确保调用服务二进制文件以及服务二进制文件本身不执行或很少执行初始化（并且其初始化不太可能失败）的情况，可能是一种选择。请注意，使用除了simple之外的任何类型都可能会延迟启动过程，因为服务管理器需要等待服务初始化完成。因此建议不要不必要地使用除simple以外的任何类型。（另请注意，对于长时间运行的服务，一般不建议使用idle或 oneshot。）

注意：

focking模式下，程序正常自我退出，如os.Exit(0),会调用systemd服务的stop，异常退出，如os.Exit(1)不会调用stop