文章目录

为什么要将程序配置成服务？1. 自动启动2. 后台运行3. 定时重启4. 简化管理5. 整合系统6. 自动日志 版本支持1. Ubuntu 14.04及更早版本：使用`upstart`作为默认的init系统/etc/rc.local旧版本新版本 2. Ubuntu 15.04到16.04版本：默认使用`systemd`作为init系统，但仍然兼容`upstart`3. Ubuntu 16.10及更高版本：默认使用`systemd`作为init系统总结 开机自启服务原理配置步骤1. 创建配置文件2. 编辑配置文件3. 拷贝配置文件4. 启用服务5. 启动服务6. 停止服务7. 禁用服务 配置项解释配置父项配置子项`[Unit]`配置子项- `Description`：用于设置服务的描述信息。- `Requires`：用于指定服务所依赖的其他服务。- `After`：用于指定服务启动的顺序，可以设置在哪些服务之后启动。- `Before`：用于指定服务启动的顺序，可以设置在哪些服务之前启动。 `[Service]`配置子项- `Type`：定义服务单元的启动类型，决定systemd如何理解服务的启动和运行状态1. simple2. forking3. oneshot4. dbus5. notify6. idle - `ExecStart`：用于指定服务的启动命令。- `WorkingDirectory`：用于指定服务的工作目录。- `Environment`：用于设置服务的环境变量。- `User`：用于指定服务运行的用户。- `Group`：用于指定服务运行的用户组。 `[Install]`配置子项- `WantedBy`：用于指定服务在哪些目标（target）下启动。`After=`和`WantedBy=`区别 - `RequiredBy`：用于指定哪些目标（target）依赖于该服务。 systemd官方文档（systemd.service完整配置选项）vscode相关插件：Systemd Helper使用软链接链接systemd配置文件步骤注意：如果用软链接配置，disable服务时，会将/etc/systemd/system下的.service软链接删除；但是如果是普通文件方式，disable服务时，不会将/etc/systemd/system下的.service文件删除 systemd服务配置相关指令- `systemctl start <service>`：启动一个服务。- `systemctl stop <service>`：停止一个服务。- `systemctl restart <service>`：重启一个服务。- `systemctl reload <service>`：重新加载一个服务的配置文件，使其生效。- `systemctl enable <service>`：设置一个服务在系统启动时自动启用。- `systemctl disable <service>`：设置一个服务在系统启动时不自动启用。- `systemctl status <service>`：查看一个服务的状态，包括是否正在运行、最后一次的活动时间等信息。- `systemctl is-active <service>`：检查一个服务是否正在运行。- `systemctl is-enabled <service>`：检查一个服务是否已经设置为在系统启动时自动启用。- `systemctl list-units`：列出所有正在运行的单位（包括服务、套接字、挂载点等）。- `systemctl list-unit-files`：列出所有可用的单位文件（包括服务、套接字、挂载点等）。 systemd其他指令查看systemd服务日志（journalctl -u $SERVICE_NAME --no-pager -u $LINE_COUNT） systemd支持在/etc/systemd/system创建子目录，便于我们方便管理我们的.service文件（没成功）测试1：创建子目录，在子目录中创建软链接，[执行systemctl daemon-reload]，执行system enable xxx，报错：Failed to enable unit: Unit file xxx.service does not exist.测试2：创建子目录，将.service文件拷贝到子目录，[执行systemctl daemon-reload]，执行system enable xxx，报错：Failed to enable unit: Unit file xxx.service does not exist.测试3：不创建子目录，创建软链接到/etc/systemd/system下，[执行systemctl daemon-reload]，执行system enable xxx，成功 配置示例20230802ky_ai_convert_video.service测试

为什么要将程序配置成服务？

我们在linux系统下启动一个程序，一般用一条命令，或者执行一个脚本就行了，那么，为什么还要将程序配置成服务？这样做有什么好处？

1. 自动启动

配置成服务后，程序将在系统启动时自动启动，无需手动操作。这样可以确保程序在系统重启后能够自动运行，避免因为人为疏忽或其他原因导致程序未能启动。

2. 后台运行

配置成服务后，程序将以后台进程的方式运行，不会占用终端或用户会话。这样可以确保程序在后台持续运行，即使用户注销或关闭终端。

3. 定时重启

通过配置服务，可以设置服务在异常退出时自动重启。这样可以提高程序的稳定性，确保在出现问题时能够及时恢复运行。

4. 简化管理

配置成服务后，可以使用系统工具（如systemctl）来管理服务，如启动、停止、重启、查看状态等。这样可以方便地管理和监控程序的运行状态。

5. 整合系统

配置成服务后，程序可以与系统的其他服务和组件进行整合。例如，可以设置服务的依赖关系，确保在其他服务启动之前先启动该服务；还可以将服务与日志记录、监控系统等集成，方便管理和故障排查。

6. 自动日志

配置成服务后，系统会自动搜集服务的日志信息，甭管你是c++程序，还是java程序，还是python程序，还是shell脚本，都可以搜集，可以用以下命令查看：

journalctl -u 服务名 --no-pager

版本支持

在不同的Ubuntu版本中，配置开机自启服务的方式可能会有所不同。以下是几个常见的Ubuntu版本和它们支持的开机自启服务类型。本文主要讲解Ubuntu 16.10及更高版本，使用systemd作为init系统的服务开机自启方式。

1. Ubuntu 14.04及更早版本：使用upstart作为默认的init系统

可以创建一个.conf文件来配置开机自启服务，然后将它放在/etc/init/目录下。

/etc/rc.local

旧版本

rc.local是一种在Ubuntu中配置开机自启服务的方式，它属于早期版本的init系统。具体来说，rc.local是在Ubuntu 14.04及更早版本中使用的方式，使用的是upstart作为默认的init系统。

rc.local是一个脚本文件，位于/etc/rc.local。你可以在该文件中添加要在系统启动时执行的命令或脚本。这些命令或脚本将在系统启动时自动执行。

以下是使用rc.local配置开机自启服务的步骤：

打开rc.local文件：

sudo nano /etc/rc.local

在文件中添加你要执行的命令或脚本。例如，如果要启动一个名为my_service的服务，可以添加以下内容：

/path/to/your/service

注意，命令或脚本必须是可执行的。

保存并关闭文件。

确保rc.local文件具有可执行权限：

sudo chmod +x /etc/rc.local

重启系统，服务将在系统启动时自动执行。

需要注意的是，rc.local方式在较新的Ubuntu版本中已经不再推荐使用，因为它是基于旧的upstart系统。对于使用systemd作为init系统的较新版本的Ubuntu，建议使用systemd的方式来配置开机自启服务。

新版本

在一些较新的Ubuntu版本中，如Ubuntu 16.04及更高版本，rc.local文件默认是被禁用的，因为这些版本使用systemd作为默认的init系统。systemd不会自动执行rc.local文件中的内容。

为了在这些版本中使用rc.local文件，可以通过配置rc-local.service来实现。rc-local.service是一个systemd服务单元，用于在系统启动时执行rc.local文件中的内容。

以下是配置rc-local.service的步骤：

创建rc-local.service文件：

sudo nano /etc/systemd/system/rc-local.service

在文件中添加以下内容：

[Unit]Description=/etc/rc.local CompatibilityConditionPathExists=/etc/rc.local[Service]ExecStart=/etc/rc.local startType=forkingTimeoutSec=0RemainAfterExit=yes[Install]WantedBy=multi-user.target

创建rc.local文件：

sudo nano /etc/rc.local

在rc.local文件中添加要执行的命令或脚本。

保存并关闭文件。

设置rc.local文件的权限：

sudo chmod +x /etc/rc.local

启用rc-local.service：

sudo systemctl enable rc-local.service

启动rc-local.service：

sudo systemctl start rc-local.service

rc.local文件中的内容将在系统启动时自动执行。

对于较新的Ubuntu版本，使用rc.local和rc-local.service的方式可能不是最佳实践。推荐使用systemd的方式来配置开机自启服务，以便与当前的init系统保持一致。

2. Ubuntu 15.04到16.04版本：默认使用systemd作为init系统，但仍然兼容upstart

可以使用upstart的方式来配置开机自启服务，或者使用systemd的方式。

3. Ubuntu 16.10及更高版本：默认使用systemd作为init系统

可以使用systemd的方式来配置开机自启服务。

总结

systemd是目前主流的init系统，大多数Ubuntu版本都支持使用systemd来配置开机自启服务。但是，对于旧版本的Ubuntu，可能需要使用upstart来配置开机自启服务。

开机自启服务原理

以使用systemd作为系统初始化的管理器为例。systemd是一个Linux系统和服务管理器，它负责启动、停止和管理系统中的各种服务。

当系统启动时，systemd会读取/etc/systemd/system/目录下的服务配置文件，并根据配置文件中的指令来启动相应的服务。配置文件中的ExecStart字段指定了要执行的命令或脚本，WorkingDirectory字段指定了命令或脚本的工作目录。

通过使用systemctl enable命令，我们告诉systemd将该服务配置文件链接到系统的默认目标（default target），使得该服务在系统启动时自动启动。

当系统启动时，systemd会按照配置文件中的指令来启动服务。如果服务成功启动，systemd会将服务的状态标记为"active"。如果服务启动失败，systemd会将服务的状态标记为"failed"。

通过使用systemctl start命令，我们可以手动启动服务。而使用systemctl stop命令可以停止服务。

通过使用systemctl disable命令，我们可以禁用服务，使得该服务在系统启动时不会自动启动。

总结：使用systemd来管理服务的启动和停止，通过配置服务配置文件并将其链接到系统的默认目标，使得服务在系统启动时自动启动。

配置步骤

以systemd作为init系统的服务开机自启方式为例。下面是配置开机自启服务的步骤：

1. 创建配置文件

创建一个服务配置文件，以.service为后缀，比如my_service.service。

2. 编辑配置文件

使用文本编辑器打开该文件，并添加以下内容：

[Unit]Description=My ServiceAfter=network.target[Service]ExecStart=/path/to/your/script.shWorkingDirectory=/path/to/your/working/directory[Install]WantedBy=default.target

在上面的配置中，需要替换/path/to/your/script.sh为你要在开机时运行的脚本的路径，/path/to/your/working/directory为脚本的工作目录。

3. 拷贝配置文件

将该服务配置文件移动到/etc/systemd/system/目录下：

sudo mv my_service.service /etc/systemd/system/

4. 启用服务

使用以下命令启用服务：

sudo systemctl enable my_service

5. 启动服务

使用以下命令启动服务：

sudo systemctl start my_service

现在，该服务将会在每次开机时自动启动。

6. 停止服务

如果需要停止服务，可以使用以下命令：

sudo systemctl stop my_service

7. 禁用服务

如果需要禁用服务，可以使用以下命令：

sudo systemctl disable my_service

配置项解释

配置父项

在systemd中，配置文件通常使用.service扩展名，并且使用INI格式。一个.service文件可以包含以下三个配置项：

[Unit]：这个配置项定义了服务的基本属性，如服务的描述、依赖关系、启动顺序等。在这个配置项中，可以设置服务的名称、描述、依赖关系、启动顺序等。

[Service]：这个配置项定义了服务的具体执行方式，如服务的启动命令、环境变量、工作目录等。在这个配置项中，可以设置服务的启动命令、环境变量、工作目录等。

[Install]：这个配置项定义了服务的安装方式，如服务的启动级别、启动顺序等。在这个配置项中，可以设置服务的启动级别、启动顺序等。

这三个配置项分别定义了服务的基本属性、具体执行方式和安装方式。

除了[Unit]、[Service]和[Install]之外，systemd还支持其他一些配置项，用于进一步定义和配置服务。以下是一些常用的配置项：

[Path]：用于监控文件或目录的变化，并在变化发生时触发服务的启动、停止或重启。

[Timer]：用于定义定时器，可以在指定的时间间隔或特定时间点触发服务的启动、停止或重启。

[Socket]：用于定义套接字，可以监听指定的网络端口或UNIX域套接字，并在有连接请求时触发服务的启动。

[Mount]：用于定义挂载点，可以在指定的文件系统挂载或卸载时触发服务的启动、停止或重启。

[Automount]：用于定义自动挂载点，可以在访问指定的文件系统路径时自动挂载该文件系统。

[Swap]：用于定义交换空间，可以在指定的交换文件或分区被启用或禁用时触发服务的启动、停止或重启。

配置子项

[Unit]配置子项

- Description：用于设置服务的描述信息。

- Requires：用于指定服务所依赖的其他服务。

- After：用于指定服务启动的顺序，可以设置在哪些服务之后启动。

- Before：用于指定服务启动的顺序，可以设置在哪些服务之前启动。

[Service]配置子项

- Type：定义服务单元的启动类型，决定systemd如何理解服务的启动和运行状态

1. simple

这是默认的服务类型，如果没有指定Type=，则假定为simple。对于此类型，一旦启动服务的主进程，systemd即认为服务已经启动成功。适合用于不会派生子进程并且在后台持续运行的应用程序。

2. forking

适用于传统的UNIX服务，这些服务启动时会派生一个子进程（即“fork”），然后父进程立即退出。这种模式常见于传统的守护进程。在这种情况下，systemd会追踪子进程，并以该子进程作为服务的主进程。

3. oneshot

此类型用于那些只执行一次性任务然后退出的服务。这通常用于初始化、配置或者更新一些系统设置然后结束的脚本。可以与RemainAfterExit=指令配合使用，以使得服务在任务执行完毕后仍显示为active。

4. dbus

如果服务在D-Bus上注册自己，可以使用这个类型。systemd将等待服务出现在D-Bus消息总线上才认为服务已经启动成功。适合于那些提供D-Bus接口的守护进程。

5. notify

这种类型的服务会在准备就绪时向systemd发送一个信号。这要求服务具有实现了sd_notify协议的逻辑，通过它来告知systemd其状态。只有收到了服务发出的就绪通知，systemd才会认为服务启动成功。

6. idle

idle 类型类似于simple类型，但是它会延迟服务的启动直到所有其他空闲任务都完成了。这主要用于那些希望在系统负载低时运行的服务，以避免影响到其他更重要的启动任务。

- ExecStart：用于指定服务的启动命令。

- WorkingDirectory：用于指定服务的工作目录。

- Environment：用于设置服务的环境变量。

- User：用于指定服务运行的用户。

- Group：用于指定服务运行的用户组。

[Install]配置子项

- WantedBy：用于指定服务在哪些目标（target）下启动。

WantedBy是systemd服务配置文件中的一个选项，用于指定服务所属的启动级别（target）。启动级别是一组定义了系统启动过程中要启动的服务的目标单元的集合。

在systemd中，启动级别由target单元来表示。每个target单元都是一组相关的服务单元的集合，用于定义系统在不同阶段启动时应该启动哪些服务。例如，multi-user.target是一个常见的启动级别，用于表示系统已经启动到多用户模式，此时应该启动所有与用户交互相关的服务。

WantedBy选项用于指定服务所属的启动级别。它接受一个目标单元的名称作为参数。当你将服务配置文件放置在/etc/systemd/system/目录下，并使用systemctl enable命令启用服务时，systemd会根据WantedBy选项中指定的目标单元，将服务添加到相应的启动级别中。

在上面的例子中，WantedBy=multi-user.target表示该服务应该属于multi-user.target启动级别，即系统已经启动到多用户模式时应该启动该服务。

在systemd中，有以下几个常见的启动级别（target）：

poweroff.target：系统关机时的目标单元。rescue.target：用于系统救援的目标单元，提供了一个最小的功能集合，用于修复系统问题。multi-user.target：多用户模式的目标单元，用于正常的多用户操作。graphical.target：图形界面模式的目标单元，用于启动图形界面环境。reboot.target：系统重启时的目标单元。

除了上述常见的启动级别，还有其他一些特定的启动级别，如network.target（网络启动完成后的目标单元）、default.target（默认目标单元，通常是multi-user.target或graphical.target）等。

对于普通程序来说，通常会将其配置为属于multi-user.target或graphical.target这样的启动级别，以便在系统启动到多用户模式或图形界面模式时自动启动。你可以根据你的需求选择适合的启动级别。

After=和WantedBy=区别

以After=multi-user.target和WantedBy=multi-user.target为例，它们确实在某种程度上相关，但它们服务于不同的目的，并且不是重复的功能。

After=multi-user.target:

这个配置项位于[Unit]部分，用来指定当前服务应当在哪些其他单元之后启动。换句话说，它定义了服务启动的顺序。在这个例子中，After=multi-user.target表明该服务应该在系统达到multi-user.target（多用户目标状态，类似于传统的运行级别3）之后启动。这意味着网络等基础设施应该已经设置好了。

WantedBy=multi-user.target:

这个配置项位于[Install]部分，它指定了当你使用systemctl enable命令来使服务自启动时，应该将这个服务链接到哪个目标的“wanted”目录下。WantedBy=multi-user.target表示当系统达到多用户目标状态时，这个服务应该被认为是“所需的”或“期望的”，因此应该被启动。简而言之，它用来定义服务是否应该随着特定的target自动启动。

总结来说：

After= 定义了启动顺序。WantedBy= 定义了服务何时应该被自动启动。

两者共同工作以确保服务在正确的时间以正确的顺序启动。在实际情况中，一个服务通常需要在某个target之后启动（After=），并且希望随着这个target自动启动（WantedBy=）。因此，虽然它们涉及相同的target，但它们各自扮演了独特的角色。

- RequiredBy：用于指定哪些目标（target）依赖于该服务。

systemd官方文档（systemd.service完整配置选项）

https://www.freedesktop.org/software/systemd/man/systemd.service.html

vscode相关插件：Systemd Helper

可以方便我们编辑systemd配置文件：

使用软链接链接systemd配置文件

可以将.service文件创建为软链接，链接到实际文件。这样做可以使服务配置文件保持在原始位置，同时在/etc/systemd/system目录下创建一个链接，以便systemd能够找到并管理该服务。

步骤

以下是创建软链接的步骤：

在/etc/systemd/system目录下创建一个软链接，链接到实际文件。例如，假设实际文件位于/path/to/my-service/my-service.service，可以使用以下命令创建软链接：

sudo ln -s /path/to/my-service/my-service.service /etc/systemd/system/ 或者：

sudo ln -s /path/to/my-service/my-service.service /etc/systemd/system/my-service.service

注意：systemd要求软链接必须与目标名称相同，如果不同执行systemctl enable xxx时将报Failed to enable unit: File xxx.service: Link has been severed错误

确保软链接的文件权限正确设置。一般来说，软链接的所有者应为root用户，权限应为644：

sudo chown root:root /etc/systemd/system/my-service.servicesudo chmod 644 /etc/systemd/system/my-service.service

通过这种方式，服务配置文件将保持在原始位置，而软链接将位于/etc/systemd/system目录下，使systemd能够找到并管理该服务。这样做的好处是，当需要修改或更新服务配置文件时，只需在原始位置进行操作，而不需要修改软链接。

注意：如果用软链接配置，disable服务时，会将/etc/systemd/system下的.service软链接删除；但是如果是普通文件方式，disable服务时，不会将/etc/systemd/system下的.service文件删除

请看下面测试示例：

普通.service文件方式（将.service文件拷贝到/etc/systemd/system下）：

root@nvidia:/userdata/testOnebuttonDeploy/shsany_ai/clean_up# systemctl enable ky_ai_algo_manager.service Created symlink /etc/systemd/system/default.target.wants/ky_ai_algo_manager.service → /etc/systemd/system/ky_ai_algo_manager.service.root@nvidia:/userdata/testOnebuttonDeploy/shsany_ai/clean_up# root@nvidia:/userdata/testOnebuttonDeploy/shsany_ai/clean_up# systemctl disable ky_ai_algo_manager.service Removed /etc/systemd/system/default.target.wants/ky_ai_algo_manager.service.root@nvidia:/userdata/testOnebuttonDeploy/shsany_ai/clean_up# root@nvidia:/userdata/testOnebuttonDeploy/shsany_ai/clean_up# ll /etc/systemd/system/ky_ai_algo_manager.service-rwxr-xr-x 1 root root 240 Aug 16 11:36 /etc/systemd/system/ky_ai_algo_manager.service* 软链接方式（在/etc/systemd/system中创建软链接链接到实际文件）：

root@nvidia:/userdata/testOnebuttonDeploy/shsany_ai/clean_up# systemctl disable ky_ai_algo_managerRemoved /etc/systemd/system/ky_ai_algo_manager.service.Removed /etc/systemd/system/default.target.wants/ky_ai_algo_manager.service.root@nvidia:/userdata/testOnebuttonDeploy/shsany_ai/clean_up# root@nvidia:/userdata/testOnebuttonDeploy/shsany_ai/clean_up# root@nvidia:/userdata/testOnebuttonDeploy/shsany_ai/clean_up# ll /etc/systemd/system/ky_ai_algo_manager.servicels: cannot access '/etc/systemd/system/ky_ai_algo_manager.service': No such file or directory

systemd服务配置相关指令

- systemctl start <service>：启动一个服务。

- systemctl stop <service>：停止一个服务。

- systemctl restart <service>：重启一个服务。

- systemctl reload <service>：重新加载一个服务的配置文件，使其生效。

- systemctl enable <service>：设置一个服务在系统启动时自动启用。

- systemctl disable <service>：设置一个服务在系统启动时不自动启用。

- systemctl status <service>：查看一个服务的状态，包括是否正在运行、最后一次的活动时间等信息。

注意，使用systemctl status查看某个服务状态时，可能因为服务日志信息太长产生分页，阻塞程序执行，这时可以加个--no-pager选项屏蔽（suppress）分页，如：systemctl status $SERVICE_NAME --no-pager

- systemctl is-active <service>：检查一个服务是否正在运行。

- systemctl is-enabled <service>：检查一个服务是否已经设置为在系统启动时自动启用。

- systemctl list-units：列出所有正在运行的单位（包括服务、套接字、挂载点等）。

- systemctl list-unit-files：列出所有可用的单位文件（包括服务、套接字、挂载点等）。

systemd其他指令

查看systemd服务日志（journalctl -u $SERVICE_NAME --no-pager -u $LINE_COUNT）

查看systemd某个服务的日志，可以使用journalctl命令。journalctl命令用于查看systemd日志，包括系统日志和服务日志。

要查看某个服务的日志，可以使用以下命令：

journalctl -u $SERVICE_NAME

其中，$SERVICE_NAME是要查看日志的服务名称。这将显示与该服务相关的日志条目。

还可以使用其他选项来进一步筛选和格式化日志。例如，可以使用-n选项指定要显示的日志条目数量，使用-f选项实时跟踪日志，使用--since和--until选项指定时间范围等。

以下是一些示例命令：

# 显示最近的10条服务日志journalctl -u $SERVICE_NAME -n 10# 实时跟踪服务日志journalctl -u $SERVICE_NAME -f# 显示指定时间范围内的服务日志journalctl -u $SERVICE_NAME --since "2022-01-01" --until "2022-01-02"

systemd支持在/etc/systemd/system创建子目录，便于我们方便管理我们的.service文件（没成功）

systemd会递归遍历/etc/systemd/system目录下的所有.service文件以及子目录中的.service文件。这意味着可以在/etc/systemd/system目录下创建子目录，并在子目录中放置您的服务配置文件。

例如，如果在/etc/systemd/system目录下创建了一个名为my-service的子目录，并将服务配置文件my-service.service放置在该子目录中，systemd仍然能够找到并管理该服务。

这种递归遍历的机制使得您可以更好地组织和管理多个服务的配置文件，而不会造成混乱。

测试1：创建子目录，在子目录中创建软链接，[执行systemctl daemon-reload]，执行system enable xxx，报错：Failed to enable unit: Unit file xxx.service does not exist.

[]为可选，下同

测试2：创建子目录，将.service文件拷贝到子目录，[执行systemctl daemon-reload]，执行system enable xxx，报错：Failed to enable unit: Unit file xxx.service does not exist.

测试3：不创建子目录，创建软链接到/etc/systemd/system下，[执行systemctl daemon-reload]，执行system enable xxx，成功

莫非只能在/etc/systemd/system下？不支持子目录？

配置示例

20230802

ky_ai_convert_video.service

[Unit]Description=ky_ai_convert_videoAfter=network.target[Service]ExecStart=/ky/tml/ky_ai_convert_video/kyai_video_converterWorkingDirectory=/ky/tml/ky_ai_convert_videoRestart=alwaysRestartSec=3[Install]WantedBy=default.target

测试

开个log监控：tail -f ky_ai_api.log

杀进程：

ps -ef | grep convertkill <pid>

发现过三秒就又起来了：

重启测试：

程序运行正常