add_service: 便捷添加 systemd 开机自启启动项的 CLI 工具

[diyer22]

在 Linux 系统中， 配置 systemd service 实现开机自启的过程复杂且繁琐。为了方便，我写了一个用于管理开机启动项的 CLI 小工具 —— add_service

https://github.com/DIYer22/add_service

它仅需一行命令，即可便捷添加 systemd 启动项，无需手动编写配置文件。

安装:

pip3 install add_service

使用方法:

add_service xxx.sh/cmd [--user root(默认为 `whoami`)] [--name service_name] [--start]

可选参数:

-h, --help 显示此帮助信息并退出
-l, --ls 列出所有由 add_service 创建的服务
--rm NAME 删除由 add_service 创建的服务
--user USER 执行脚本的用户，默认为 whoami
--name NAME 服务名称，默认为 add_service0.service
--start 立即启动服务

示例:

把当前文件夹开一个 http 服务器并暴露到 80 端口:

add_service "`which python3` -m http.server 80" --user root --name http_server

python -m 调用方式来开机自动运行 ssh_nat.sh 文件(执行用户是当前用户):

python -m add_service ssh_nat.sh   # 默认服务名称为 ssh_nat.service

欢迎 V 友们使用和提意见！

[ExplodingFKL]

支持 「 Systemd User Services 」吗？

https://wiki.archlinux.org/title/systemd/User

[cheng6563]

我还是倾向于写配置文件，直接用命令注册服务，万一命令打错了，之前命令怎么写的都不知道。

[diyer22]

@ExplodingFKL 目前不支持, 感受了一下 systemd/User, 没有太明白其应用场景; add_service 主要的目的是便捷地添加 systemd 开机自启启动项, 所以不宜变得复杂, 保持简洁为好.

[diyer22]

@cheng6563 哈哈哈, 命令打错这种事情太常见了. 所以开发的时候也考虑了这方面. add_service 纯粹就是自动化地按照人们的预期创建 service 文件和执行 systemctl 命令.
且为了透明性, add_service 会在 terminal 上 log 出它要做的全部操作(可以在项目主页看到详细 log). 做错了很方便根据 log 删除对应的文件, 也可以一行删除 `add_service --rm service_name`.

[julyclyde]

这种需求太低频，且太个性化
做个工具的用处不大

[diyer22]

@julyclyde 的确很低频. 但一个是 systemd 太复杂, 繁琐了, 二是我工作上经常要配置新电脑, 用到的频率偏高一些. 所以就写了这个工具, 希望对有类似需求的人有用吧.

[skyrim61]

便捷添加 systemd 启动项 和写 配置文件 有啥区别? 我从来没听过还有这种方式

[diyer22]

@skyrim61 没有区别。 只是配置 service 来写启动项太繁琐了， 需要创建文件，修改 n 个配置参数，然后至少两个 systemctl 命令才能完成， 而且配置文件很多小细节没做好就得 debug+重新修改。

所以我开发了小工具 add_service ， 一行命令就可以无脑完成 service + 设置启动项，非常方便。

[julyclyde]

@diyer22 你这工具能一次性写好细节避免修改？

[diyer22]

@julyclyde add_service 在 shell 命令和 service 文件要求的细节对齐上, 做了很多工作(if else + assert). 能避免绝大多数问题, 我知道的坑都有单独代码处理.
其可以支持开机自启运行 二进制/shell/Python/JS/TS 等脚本. 最关键的是有一个克隆环境变量的功能(--clone-envs), 能做到和当前 shell 一致的运行环境, 避免了很多环境变量不同的坑.

[yanqiyu]

其实我一直用的土办法：
先 systemd-run 把东西跑起来，然后修改产生的 transient unit file 作为 unit file