开头一说起 systemd可能很多人第一反应是“开机启动的”再问深入一点就剩一堆systemctl命令背了又忘。其实 systemd 里最核心的两个概念就是service和target一个是“怎么把一个程序跑起来”一个是“系统到底要跑到什么状态”。这两样弄明白了日常运维里的服务管理、开机自启、系统切换状态基本都能顺下来。这篇文章从实用角度出发把service和target的完整用法、文件结构、命令参数、常见报错一锅端出来。无论你是刚接触 Linux 的新手还是已经被 systemd 坑过几次的运维都可以照着里面的步骤实操一遍。像job for docker.service failed、service redis does not support chkconfig这类高频问题也会在最后一章专门拆解看完就能直接排查。1. systemd 到底解决了什么问题从启动脚本到依赖管理1.1 老派 init 的痛点以及 systemd 的破局思路在 systemd 出现之前Linux 用的是 SysV init系统启动就是按顺序执行/etc/rc.d/下面一堆脚本。这种方式最大的问题是“串行”一个服务起完了才轮到下一个开机越来越慢。而且脚本之间的依赖关系全靠人肉约定经常出现“我明明把 nginx 排在 database 后面了结果数据库还没就绪nginx 已经报错退出”的尴尬。systemd 把思路整个换掉了不按顺序排队而是把每个服务声明成独立单元标清楚“我依赖谁”“谁依赖我”然后并行启动。启动速度明显提升依赖关系也通过配置显性化了。这就是为什么现在主流发行版全部切到 systemd因为它的模型确实更符合现代服务器的复杂度。1.2 Unit单元模型一切服务都是文件systemd 里所有可被管理的对象都叫unit中文叫“单元”。它们统一以.service、.target、.socket、.timer、.mount这类后缀结尾本质就是一个.ini风格的文本文件。你不需要理解太多抽象的东西只要记住一句话unit 就是文件管理 unit 就是管理文件。常见的 unit 类型有这些service定义一个后台服务进程比如 nginx、docker、sshd。target定义一组 unit 的逻辑集合对应“系统状态”比如多用户模式、图形界面模式。socket定义 socket 监听可以做到按需启动服务比如客户端一连接才拉起对应服务。timer定义定时任务替代 crontab 的一种方式。mount/automount定义挂载点和自动挂载行为。path监控文件或目录变化触发服务。日常用到的 90% 场景就是service和target这也是这篇文章的主角。1.3 service 与 target 的关系服务是谁状态是什么把电脑比作一个公司service就是具体干活的员工比如 sshd 负责接待远程连接nginx 负责处理网页请求。而target就是公司的工作模式上班模式multi-user、带展厅的接待模式graphical、下班关机poweroff。一个 target 里可以包含很多个 service它不直接“运行”什么而是通过在配置里声明依赖和引用来决定要拉起哪些服务。你执行systemctl isolate multi-user.target实际上就是让系统停掉不在这个 target 里的服务、启动需要的服务最终把系统切到对应的运行状态。这就是整个 systemd 管理模型的核心逻辑。2. service 单元从零编写到常用命令2.1 service 文件放哪里优先级怎么判断service 文件的标准位置有三个按优先级从高到低排列/etc/systemd/system/管理员手动创建或修改的地方优先级最高。/run/systemd/system/运行时生成的临时单元重启后消失。/usr/lib/systemd/system/软件包安装时自带的单元文件也就是发行版默认配置。为什么要分这么多层因为 systemd 允许你用高优先级目录里的文件覆盖低优先级目录里的同名文件。比如 nginx 包自带的/usr/lib/systemd/system/nginx.service你想调参数不要直接改原文件而是复制一份到/etc/systemd/system/nginx.service再改。这样软件包升级时原文件被替换了你的自定义配置依然生效。查看当前某个服务实际生效的是哪个文件用systemctl cat nginx.service就能看到完整内容和来源路径。2.2 service 文件的三段式结构Unit、Service、Install一个标准的 service 文件长成这样[Unit] DescriptionMy Custom Web Server Afternetwork.target Wantsnetwork-online.target [Service] Typesimple Userwww-data WorkingDirectory/var/www/html EnvironmentFile/etc/myapp/env.conf ExecStart/usr/local/bin/myapp --config /etc/myapp/config.yaml ExecReload/bin/kill -HUP $MAINPID Restarton-failure RestartSec3 [Install] WantedBymulti-user.target逐个拆解一下[Unit]段描述这个服务的基本信息和依赖关系。Description服务说明systemctl status里能看到。After注明本服务应该在哪些 unit 之后再启动控制顺序。Wants弱依赖有就启动没有或失败不影响本服务。Requires强依赖如果依赖的 unit 启动失败本服务也会启动失败。Before与 After 相反声明本服务要在某个 unit 之前启动。注意After只管启动顺序不负责把依赖拉起来“拉起依赖”是Wants或Requires的职责。两者经常配合使用用Wants声明依赖用After控制先后。[Service]段定义服务怎么运行这是最核心的部分。Type服务进程类型。simple表示主进程直接在前台运行forking表示主进程会 fork 一个子进程父进程退出常见于传统 daemon 程序oneshot用于一次性任务执行完就退出notify表示进程启动完成后会通过 sd_notify 通知 systemd。ExecStart启动命令必须是绝对路径。注意这里不是 shell不能写管道符、重定向这类语法。ExecStartPre/ExecStartPost在启动前或启动后执行的附加命令。ExecReload重载操作一般用来发信号给服务进程。ExecStop停止命令不写的话 systemd 会先发 SIGTERM再发 SIGKILL。Restart进程退出后是否自动拉起。always是任何情况都重启on-failure是非正常退出才重启。对于 web 服务always更稳妥对于批量任务on-failure更合适。RestartSec重启前等待的秒数防止疯狂重启打满 CPU。User/Group以哪个用户身份运行服务。安全底线不要用 root 跑业务服务。Environment/EnvironmentFile设置环境变量EnvironmentFile可以外挂一个配置文件。WorkingDirectory工作目录。StandardOutput/StandardError标准输出和错误日志去向默认走 systemd journal。[Install]段用于定义服务“被启用”时怎么挂到系统里。WantedBy最常用的一个表示执行systemctl enable时会在对应 target 的.wants目录里创建一个软链接。比如WantedBymulti-user.targetenable 之后/etc/systemd/system/multi-user.target.wants/下就多了个指向你的 service 的链接。RequiredBy效果类似但创建在.requires目录里是强依赖关系。Alias给服务起别名enable 时一并创建符号链接。2.3 实操五分钟写一个自己的 service假设我手头有一个 Python 写的 web 服务/opt/myapp/server.py需要以www-data用户运行监听 8000 端口。现在把它做成系统服务。第一步创建 service 文件sudo vim /etc/systemd/system/myapp.service写入内容[Unit] DescriptionMy Python Web App Afternetwork.target [Service] Typesimple Userwww-data Groupwww-data WorkingDirectory/opt/myapp ExecStart/usr/bin/python3 /opt/myapp/server.py Restartalways RestartSec5 EnvironmentAPP_ENVproduction [Install] WantedBymulti-user.target第二步重载 systemd 配置并启动sudo systemctl daemon-reload sudo systemctl start myapp.service sudo systemctl status myapp.servicedaemon-reload这步千万不能省。你改了 service 文件之后systemd 不会自动发现变化不执行daemon-reload的话启动的可能还是旧配置。我见过不少新手在配置文件里加了一行然后反复 restart发现没生效就是因为忘了先 reload。第三步设置开机自启sudo systemctl enable myapp.serviceenable 的本质就是在/etc/systemd/system/multi-user.target.wants/下面创建一个指向/etc/systemd/system/myapp.service的软链接。手动画等号的话enable 和这个命令等价ln -s /etc/systemd/system/myapp.service /etc/systemd/system/multi-user.target.wants/myapp.service看到这里就明白systemd 没什么魔法一切行为都是文件和链接的组合。2.4 service 相关命令速查命令作用systemctl start foo.service立即启动服务systemctl stop foo.service停止服务systemctl restart foo.service重启服务相当于 stop startsystemctl reload foo.service发送重载信号不中断服务依赖 ExecReloadsystemctl enable foo.service设置开机自启创建软链接systemctl disable foo.service取消开机自启删除软链接systemctl status foo.service查看服务状态和最近日志systemctl is-active foo.service只输出 active 或 inactive适合脚本判断systemctl is-enabled foo.service输出 enabled 或 disabled判断是否开机自启systemctl cat foo.service查看完整 unit 配置和文件路径systemctl show foo.service查看全部运行时属性排障利器systemctl list-units --typeservice列出所有已加载的 service 单元systemctl list-unit-files --typeservice列出所有 service 文件及启用状态systemctl kill foo.service给服务进程发信号强杀时用有一类常见误区enable和start是两个动作。enable只负责开机自启不立即启动start只负责现在运行不改开机设置。很多服务配置完发现“现在能跑重启就废了”基本就是只 start 忘 enable。3. target 单元系统状态的真正控制者3.1 target 是什么unit 的逻辑分组target 从形式上讲也是一个 unit 文件后缀是.target。它的内容通常非常简单没有ExecStart核心是依赖关系[Unit] DescriptionMulti-User System Documentationman:systemd.special(7) Requiresbasic.target Conflictsrescue.service rescue.target Afterbasic.target rescue.service rescue.target AllowIsolateyes这段配置什么意思Requiresbasic.target说明要进入 multi-user 状态必须先满足 basic.targetConflicts说明它和救援模式互斥AllowIsolateyes表示这个 target 可以作为systemctl isolate的目标。target 本质就是一堆 unit 的“汇总入口”。通过依赖关系和Wants/Requires它把一堆服务聚合成一个可切换的系统状态。这也是为什么我前面说“target 对应系统状态”因为它决定了服务集合的整体去留。3.2 常用 target 一览以及和运行级别的对应在旧的 SysV init 里有运行级别 0-6systemd 用 target 取代了这套体系。对照关系如下systemd target旧运行级别作用poweroff.target0关机rescue.target1单用户救援模式最小环境multi-user.target3多用户命令行模式无图形界面graphical.target5多用户图形界面模式reboot.target6重启日常运维中打交道最多的是multi-user.target和graphical.target。大部分服务器跑在multi-user.target带桌面的系统默认目标才是graphical.target。用systemctl get-default查看当前默认的启动 target用systemctl set-default multi-user.target把默认启动目标改成命令行模式。set-default实际就是修改/etc/systemd/system/default.target这个软链接的指向你可以用ls -l验证。3.3 如何把 service 挂到 target 上enable 的秘密前面讲 service 的时候提过WantedBy会在对应 target 的.wants目录里创建软链接这就是 service 和 target 衔接的关键机制。执行sudo systemctl enable myapp.service之后你会发现ls -l /etc/systemd/system/multi-user.target.wants/里面有myapp.service - /etc/systemd/system/myapp.service这样的软链接。这个软链接就表示“当系统进入 multi-user.target 时会自动拉起 myapp.service”。如果你想手动建立一个“进入某个 target 时自动启动服务”的关系也可以自己写软链接不需要工具。但更规范的做法是在 service 文件的[Install]段写WantedBymulti-user.target然后 enable。这样既清晰又可重复执行。3.4 target 切换的实操命令# 查看当前 target systemctl get-default # 设置默认 target sudo systemctl set-default multi-user.target # 切换到救援模式 sudo systemctl rescue # 切入某个 target不改变默认设置 sudo systemctl isolate multi-user.target # 重启 / 关机 sudo systemctl reboot sudo systemctl poweroff关于isolate有个重要坑不是所有 target 都允许 isolate。只有配置了AllowIsolateyes的 target 才能被切换。执行systemctl isolate前建议先systemctl list-units --typetarget看一眼当前有哪些 target其中一部分用于内部组合比如 basic.target一部分用于切换状态比如 multi-user.target。rescue也是生产环境排障常用操作系统起不来时进救援模式只挂载最基础的文件系统方便你修复配置。从救援模式退回完整系统执行systemctl isolate multi-user.target或者直接systemctl default默认 target。3.5 自定义 target按业务场景整合理想状态target 也可以自己建。比如我有一组服务是“数据处理任务”包括etl.service、worker.service、cleaner.service。与其每次一个个启动不如建一个自定义 target[Unit] DescriptionData Processing Stack Requiresetl.service worker.service cleaner.service Afternetwork.target保存在/etc/systemd/system/data-processing.target然后sudo systemctl daemon-reload sudo systemctl isolate>Job for docker.service failed because the control process exited with error code. See systemctl status docker.service and journalctl -xeu docker.service for details.这个报错本身只是“结果”真正原因要看后边的提示。正确排查顺序是systemctl status docker.service journalctl -xe -u docker.servicestatus会显示进程的退出码和最后几行日志journalctl -xeu能打印完整日志。常见原因就那几类配置文件语法错误进程起不来端口被占用Address already in use权限不对Permission denied依赖项没就绪比如数据库还没起来。处理思路先看日志定位直接原因修完配置后daemon-reload再启动。不要反复无脑 restart日志不会撒谎。4.2 service redis does not support chkconfig旧命令的无效操作很多老教程还在用chkconfig redis on、chkconfig --list这套 SysV 时代的命令。在新系统上执行会得到service redis does not support chkconfig这个报错的意思是当前系统的服务管理已经是 systemd 了redis 的启动脚本不提供 chkconfig 支持。你不需要 chkconfig直接用 systemctlsudo systemctl enable redis sudo systemctl start redis类似的情况还有service redis start这种写法在部分发行版上可能仍能通过兼容层执行但终极目标都是转发给 systemctl。熟悉现代语法少走弯路。4.3 指定的服务已标记为删除系统状态残留报错形式lash helper service 指定的服务已标记为删除。这通常发生在 Windows 场景但换成 Linux systemd 也有类似现象service 文件被删除或 disable 时某些进程还残留着旧状态导致 systemd 认为服务处于“待删除”标记状态。处理办法sudo systemctl daemon-reload sudo systemctl reset-faileddaemon-reload让 systemd 重新扫描 unit 文件reset-failed清掉失败状态。如果还不行检查是否有多余的软链接残留在/etc/systemd/system/*.wants/目录下手动清掉即可。4.4 修改配置不生效、日志找不到这些坑你迟早遇到第一个坑改完 service 文件忘记daemon-reload。这是 systemd 和传统 init 最大的差别之一传统 init 改完脚本立即生效systemd 不行。我的习惯是每次改完配置文件先执行systemctl daemon-reload再执行 restart形成肌肉记忆。第二个坑日志不知道去哪看。systemd 管的服务日志默认进 journal用journalctl -u 服务名查看。如果希望把服务日志输出到文件可以在[Service]里写StandardOutputappend:/var/log/myapp.log StandardErrorappend:/var/log/myapp.err但注意append:语法要求 systemd 版本够新老版本可能不支持。第三个坑Restartalways配合“服务自己退出”的场景。如果程序逻辑是跑完任务主动exit(0)你可能并不希望它被反复拉起来。这时候要用on-failure只在真正出错时重启。第四个坑ExecStart不支持 shell 语法。很多人想写ExecStart/bin/sh -c command1 command2乍一看没问题仔细一看才发现忘写-c。正确写法是ExecStart/bin/sh -c /usr/bin/command1 /usr/bin/command2一定要把解释器显式写出来因为 systemd 不会帮你套 shell。4.5 清理 unit 状态systemctl reset-failed 的正确用法服务启动失败后systemd 会把这个 unit 标记为failed状态。如果只是临时配置有误后来配置改好了你会看到有些命令会提醒你“active (failed)”此时执行sudo systemctl reset-failed myapp.service把失败计数和状态清掉再启动就正常了。这个操作在测试阶段特别常用因为反复改配置、反复启动失败后systemd 会累积错误状态不清理有时会阻碍后续操作。5. 把时间花在理解模型上而不是背命令systemd 的命令多但真正要记的核心就一条线服务是service状态是target服务通过enable挂到 target 上系统通过 target 决定跑哪些服务。所有命令都在围绕这条线转。我自己刚接触 systemd 时也觉得很烦总觉得命令太多、文件太多直到有一天手动去翻了/etc/systemd/system/multi-user.target.wants/里的软链接突然就通了。它没有多神秘就是一堆配置文件和软链接的组合你理解了文件之间的关系命令行自然就记住了。遇到问题先journalctl -xe再systemctl status配合systemctl cat看配置九成问题都能在十分钟内定位。最后一个小技巧给服务写Afternetwork-online.target时记得确认系统里有没有对应的 network-online 服务真的在运行否则这个依赖写了也白写。类似这种看似不起眼的细节在实际部署中往往才是最磨人的地方。