Service命令在Ubuntu日常运维里算是最容易被忽略、又最容易在关键时刻救命的一类工具。很多人装完系统之后一路用systemctl可一旦接手别人留下的老脚本、老文档或者在一台跑了好几年的服务器上排查问题时跳出来的还是service nginx start这种写法。这篇东西就是围绕Ubuntu下服务的启动、关闭、重启来展开把service命令的来龙去脉、它和systemctl的对应关系、自己写一个服务并托管给系统的完整流程以及各种起不来的排查思路全部讲透。不管你是刚装完Ubuntu的新手还是已经习惯敲systemctl的老手这里面的参数取舍逻辑和踩坑记录都值得花点时间看一看。1. 别急着敲service先把Ubuntu的服务管理机制摸清动手之前我先说一个现象同一个service nginx restart在不同版本的Ubuntu上跑出来的效果可能完全不一样有人执行完日志干净利落有人执行完等十几秒还没反应。原因不在命令本身而在于这条命令背后到底由谁在执行。1.1 service命令到底是什么它把活交给了谁service本身不是一个内核组件它是一个Shell脚本通常躺在/usr/sbin/service这个位置。它的工作模式非常朴素接收你给的服务名和动作名然后判断这个服务应该由谁来处理。判断逻辑大致分两层第一层看系统上跑的是不是systemd第二层看/etc/init.d/目录下有没有对应的SysV风格脚本。在Ubuntu 15.04之后的版本里systemd已经是默认的初始化系统所以绝大多数情况下你敲service nginx start脚本内部实际上会转成systemctl start nginx去执行。而在更老的Ubuntu 14.04上同样的命令会被翻译成/etc/init.d/nginx start。这就解释了一个常见困惑为什么有些教程里service和systemctl混着用也没出问题因为它们在systemd环境下本来就是同一件事的两种入口。理解这一点很重要它意味着你不需要把service和systemctl当成两套体系去学。真正决定服务行为的是systemd的unit文件而不是你敲的是哪个命令。1.2 为什么现在依然值得把service用熟既然service只是转发层直接学systemctl不就行了理论上没错但实际环境里service有几个无法替代的场景。第一个场景是老旧文档和自动化脚本的兼容。很多企业的部署脚本、Ansible playbook、Dockerfile里写的就是service xxx start这些脚本可能跨Ubuntu、Debian、CentOS多个发行版跑用service能获得更好的兼容性因为它在Debian系和RHEL系上都存在。第二个场景是肌肉记忆和简洁性。service这个词更短语义更直白在需要快速敲命令的场合service mysql restart比systemctl restart mysql少敲好几个字符。这不是小事一天执行几十次的时候差别很明显。第三个场景是SysV脚本的兜底。有些第三方软件安装时只提供/etc/init.d/下的传统脚本没有systemd unit这时候只有service能顺畅调用它们systemctl会直接报找不到unit。提示如果service报出Unit xxx.service not found说明这个服务没有systemd unit可以去看/etc/init.d/目录下是否存在同名脚本。反过来如果systemctl找不到而service能跑通基本可以确定这是一个纯SysV脚本。1.3 动手前必须先建立的三个认知在开始敲命令之前有三个概念如果不建立起来后面排查问题会处处被动。第一服务的状态不是二元的。除了“运行中”和“已停止”还有activating正在启动、deactivating正在停止、failed启动失败、masked被屏蔽。很多人看到systemctl status输出里写着inactive (dead)就以为服务没启动过其实dead只是当前状态描述不代表历史上有过失败。第二服务名和进程名不一定一致。服务名是unit的名字比如nginx.service而它启动的实际进程可能叫nginx也可能是nginx: master process。反过来有些程序一个unit里会拉起好几个进程比如带worker的模型。排查的时候不要拿ps的输出直接和服务名对比。第三systemd会记住服务的失败状态。一个服务连续启动失败超过阈值之后会被标记为failed并且拒绝再次启动这时候你反复敲start都没用必须先reset-failed。这一点后面在排查章节会详细展开很多人第一次遇到会一脸懵。2. service命令的四类操作与参数细节命令本身的语法非常统一service 服务名 动作。动作就那么几个但每个动作背后的行为差异不小尤其是重启这一类选错了会造成连接中断或者配置没生效。2.1 启动服务start以及它返回0不代表真的起来了启动服务最常用的写法是sudo service nginx start这里的sudo不能省。原因是systemd的启动操作需要和PID 1通信普通用户没有权限会直接报Failed to start nginx.service: Interactive authentication required。执行完成之后命令返回退出码0很多人就此认为服务已经跑起来了。这是一个典型的误区。在systemd下start命令是同步等待unit进入active状态的如果unit的Typesimple那么只要进程被fork出来systemd就认为启动成功至于进程在之后0.5秒内崩溃退出start命令是不会报错的。也就是说退出码0只代表“启动动作被接受了”不代表“服务处于健康运行状态”。想确认真的起来了你需要紧接着执行service nginx status或者用systemctl is-active nginx看一眼返回值。我习惯的做法是启动后立刻查一次状态如果是生产环境的批量脚本还会加一个循环等待最多等10秒确认端口开始监听。sudo service nginx start sleep 1 systemctl is-active --quiet nginx echo 已运行 || echo 启动异常对于Typeforking的服务start的语义又不一样systemd会等待主进程fork完成并且父进程退出后才算启动成功。所以同样一条start不同unit类型下的等待时间差别很大这解释了为什么有些服务敲完立刻返回有些会卡住一两秒。2.2 关闭服务stop与真实退出时间关闭服务用sudo service nginx stop。这里的坑主要在两个地方一是服务可能关不干净二是关闭过程可能非常慢。先说不干净。systemd默认发送的是SIGTERM信号也就是让进程优雅退出释放资源、写完缓冲区、关闭连接。大部分写得规范的守护进程收到这个信号会主动退出。但有些老程序只处理SIGINT或干脆没有任何信号处理逻辑那么SIGTERM会被忽略进程继续活在内存里。systemd等一段时间后默认90秒DefaultTimeoutStopSec会发送SIGKILL强制杀掉。在这段时间里service stop这条命令是一直阻塞的不会返回。再说慢。如果你发现service stop敲下去之后光标不动了十几秒八成是程序在等待正在处理的请求完成或者卡在某个网络超时上。这种情况下的调优思路是在unit文件里显式声明超时时间而不是干等默认的90秒[Service] TimeoutStopSec15 KillSignalSIGTERM KillModemixedTimeoutStopSec设多少合适取决于业务本身。我的经验算法是先测出正常情况下优雅退出的耗时再乘以2.5到3倍作为缓冲。比如实测平均3秒退出最长一次8秒那就设20秒。给得太短会导致请求被强杀丢数据给得太长会导致发布流程卡顿20秒是个比较舒服的平衡点。KillMode这个参数值得单独说一下。默认值是control-group意思是停止服务时把整个cgroup里的所有进程全部杀掉包括主进程拉起来的子进程。改成mixed的话主进程收到SIGTERM子进程收到SIGKILL适合那种主进程需要感知子进程退出并做清理的场景。反过来如果你的服务是用shell脚本包装启动的主进程其实是个脚本真正的业务进程是它的子进程那可能更适合process模式只杀主进程而让业务进程自行处理。2.3 重启与重载restart、reload、try-restart怎么选这是最容易出错的一组命令因为它们的名字很像效果差别却很大。restart是停止加启动会完整地断开所有连接再重新建立。对于Nginx这种前置网关restart会有短暂的窗口期正在处理的请求可能被中断。对于数据库这类有连接池的服务重启意味着所有客户端连接全部掉线需要重连。所以restart不是默认选择它应该是配置改动比较大、必须重新加载进程结构时才用。reload是向服务发送重载信号通常是SIGHUP让进程重新读取配置文件而不退出。比如Nginx的reload可以做到零中断地应用新的虚拟主机配置因为master进程会先校验新配置再平滑地把worker换掉。但reload有个前提服务本身必须实现ExecReload否则systemd会直接报错。[Service] ExecReload/bin/kill -HUP $MAINPID$MAINPID是systemd提供的变量指向服务的主进程号。如果你的服务文档说支持SIGHUP热加载就需要在unit里配上这一行service xxx reload才能工作。try-restart是只在服务已经运行的情况下才重启如果当前是停止状态就直接返回成功。这个动作在批量运维里非常好用可以避免把本来就没开着的服务意外启动起来。reload-or-restart则是一个智能兜底优先尝试reloadreload失败服务不支持就退化成restart。我把这四个动作的行为整理成一张表方便对照动作是否中断连接是否需要ExecReload典型使用场景restart是否配置结构变化、升级二进制reload否是只改配置内容、加虚拟主机try-restart是否批量操作中避免误启动reload-or-restart视情况否不想判断服务是否支持reload注意reload不生效时不要反复重试。有些服务的reload只是读一遍配置但不做校验配错了也不会报错直到下一次请求进来才暴露问题。改完配置后建议先跑一次配置校验命令比如nginx -t再执行reload。2.4 status与--status-all输出到底该怎么读service nginx status的输出本质上就是systemctl status nginx的结果分几块内容我按重要性排个序。第一块是加载路径也就是Loaded:这一行它会告诉你unit文件的位置以及是否被enable。如果后面跟着disabled说明服务不会开机自启。如果显示masked说明这个服务被屏蔽了任何启动操作都会被拒绝需要先unmask。第二块是Active:这一行格式是Active: active (running) since 时间。这里最容易让人困惑的是括号里的状态描述常见的有running、exited、dead、failed。exited表示进程已经正常退出对于一次性任务型的unit是正常状态对于常驻服务就说明它挂了。第三块是Main PID和CGroup这两行在排查权限和资源问题时很有用能看到实际运行的进程号和它所属的控制组。第四块是最近几行日志通常只有5到10行够做初步判断但要完整日志还是得用journalctl。至于service --status-all这个命令会遍历/etc/init.d/下的所有脚本并逐个查询状态输出形如[ ] cron [ - ] nginx [ ? ] myservice方括号里的符号含义要记清楚表示运行中-表示已停止?表示状态未知。?出现的原因是脚本没有实现标准的status动作systemd无法判断它的状态这种情况需要单独去看进程和端口。这里有个实际经验--status-all执行速度取决于系统上有多少init脚本脚本多的时候可能要等十几秒。另外这个命令只覆盖/etc/init.d/纯systemd unit不会被列出来。想看全部服务状态用systemctl list-units --typeservice更全面。2.5 命令对照速查表把两套命令放一起对照用哪个都不会迷路操作service写法systemctl写法启动service nginx startsystemctl start nginx关闭service nginx stopsystemctl stop nginx重启service nginx restartsystemctl restart nginx重载service nginx reloadsystemctl reload nginx查状态service nginx statussystemctl status nginx是否运行无直接写法systemctl is-active nginx是否自启无直接写法systemctl is-enabled nginx全部状态service --status-allsystemctl list-units --typeservice可以看出来service覆盖的是最常用的几个动作而开关机自启这类配置性的操作只能走systemctl。所以现实中的正确姿势是日常启停用service图省事涉及配置和查询用systemctl。3. 从零跑通一遍写一个自己的服务并托管给systemd光看命令容易记不住最好的办法是拿一个自己的小程序从头到尾托管给系统跑一遍。下面用一个简单的Python HTTP服务做例子这个例子足够小能看懂又足够真实包含了账号、工作目录、环境变量这些实际项目里的要素。3.1 准备程序与运行账号先说账号。绝对不要用root跑业务服务这是硬规矩。原因很直接一旦服务被利用攻击者拿到的就是root权限整个机器就交代了。正确的做法是创建一个专用的系统账号没有登录shell没有家目录只用来跑服务。sudo useradd --system --no-create-home --shell /usr/sbin/nologin appuser sudo mkdir -p /opt/demoapi sudo chown -R appuser:appuser /opt/demoapi--system表示创建系统账号UID会在系统账号范围内分配--no-create-home是因为服务不需要家目录省得多出一个无用目录--shell /usr/sbin/nologin保证这个账号无法登录即使有人拿到了密码也没用。然后是程序本身放在/opt/demoapi/app.py内容简单到不行就是监听一个端口from http.server import BaseHTTPRequestHandler, HTTPServer import os PORT int(os.environ.get(PORT, 8080)) class Handler(BaseHTTPRequestHandler): def do_GET(self): self.send_response(200) self.send_header(Content-Type, text/plain; charsetutf-8) self.end_headers() self.wfile.write(bdemo api is running\n) def log_message(self, fmt, *args): print(%s - %s % (self.address_string(), fmt % args)) if __name__ __main__: HTTPServer((0.0.0.0, PORT), Handler).serve_forever()这里特意从环境变量读端口目的是后面演示Environment参数怎么用。日志直接打到标准输出交给journald收集这也是systemd下最推荐的做法不要自己往文件里写日志。3.2 unit文件逐段拆解与参数计算unit文件放在/etc/systemd/system/demoapi.service。为什么放这里而不是/lib/systemd/system/因为/lib/systemd/system/是软件包安装的位置系统升级或重装包的时候可能被覆盖/etc/systemd/system/的优先级更高且属于管理员的地盘不会被包管理动到。完整内容如下[Unit] DescriptionDemo API Service Documentationhttps://example.internal/demoapi Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple Userappuser Groupappuser WorkingDirectory/opt/demoapi EnvironmentPORT8080 EnvironmentFile-/etc/demoapi/env ExecStart/usr/bin/python3 /opt/demoapi/app.py ExecReload/bin/kill -HUP $MAINPID Restarton-failure RestartSec5 TimeoutStopSec20 KillSignalSIGTERM SuccessExitStatus143 StandardOutputjournal StandardErrorjournal LimitNOFILE65535 [Install] WantedBymulti-user.target逐段说清楚每个选项为什么这么写。Afternetwork-online.target和Wantsnetwork-online.target是配对使用的。After只控制启动顺序意思是网络在线之后再启动本服务Wants才是真正把network-online.target拉进来作为依赖。很多人只写After不写Wants结果发现服务启动时网络还没就绪连接外部依赖直接失败。这里用Wants而不是Requires是因为网络目标即使启动失败也不应该阻止本服务尝试启动用弱依赖更合理。Typesimple是默认值表示ExecStart启动的就是主进程systemd认为进程一fork出来服务就算起来了。这个类型适合前台运行的常驻程序。如果程序会自己daemonize就要改成Typeforking并配合PIDFile。Environment和EnvironmentFile的区别值得说一下。前者适合写少量固定值直接内联在unit里后者适合放敏感配置比如数据库密码把文件权限设成600只有root能读避免密码出现在unit文件里被随便查看。注意EnvironmentFile-前面那个减号它的含义是“文件不存在也不报错”这个设计对多环境部署很实用测试环境可以没有这个文件。Restarton-failure的含义是只有非正常退出才重启正常退出exit code 0不重启。其他可选值里always是无论怎么退出都重启适合那种绝对不能停的服务但要小心配错配置导致无限重启循环no是默认值不自动重启。RestartSec5这个值的计算有讲究。设太短服务因为依赖的下游没起来而崩溃systemd会疯狂重启日志被刷爆CPU也被吃掉设太长恢复时间变慢。我的经验是先用5秒起步观察journal日志里的重启频率如果发现30秒内重启超过3次说明问题不在重启策略上而是服务本身有问题先修问题再调参数。SuccessExitStatus143这一行容易被忽略。143是128加15代表进程被SIGTERM终止。默认情况下systemd认为收到信号退出是失败这会触发Restarton-failure导致重启循环。把143声明为成功退出码可以避免停止服务时被误判为崩溃。类似的还有130SIGINT等按实际需要加。LimitNOFILE65535是文件描述符上限。这个值的来路可以简单估算假设单实例每秒处理3000个请求每个连接平均存活0.5秒那么瞬时并发连接约1500个每个连接至少占一个fd再加上日志文件、socket、内部句柄65535这个量级留了充足余量。如果是高并发网关可能要调到六位数但要注意系统级fs.file-max也得同步放开。StandardOutputjournal表示日志交给journald这是systemd环境下的标准做法。好处是日志有统一的索引和轮转可以用journalctl -u按服务名过滤也能设总量上限避免把磁盘写满。WantedBymulti-user.target决定了systemctl enable时会创建什么符号链接。multi-user.target是常规的多用户命令行模式绝大多数服务都挂在这里。如果是图形界面相关的服务才需要考虑graphical.target。3.3 装载、启动、验证、看日志unit文件写完之后第一件事不是启动而是让systemd重新读取配置sudo systemctl daemon-reload这个命令的作用是重新扫描所有unit文件并重建依赖树。刚创建的unit文件如果不执行这一步systemctl是看不到它的会直接报Unit not found。同样的道理任何对unit文件的修改包括改环境变量、改启动命令、改依赖关系都需要重新执行一次daemon-reload。接下来是启动和验证sudo service demoapi start sudo service demoapi status如果状态显示active (running)再用端口确认一遍ss -lntp | grep 8080 curl -s http://127.0.0.1:8080ss -lntp里的参数含义是-l只看监听状态、-n不解析服务名、-t只看TCP、-p显示进程。这四条组合起来是排查端口问题的标准起手式。如果这里看不到8080那说明服务没真正监听前端再怎么配也没用。看日志用journalctl最常用的几种查法sudo journalctl -u demoapi -n 50 --no-pager sudo journalctl -u demoapi -f sudo journalctl -u demoapi --since 10 min ago -p err sudo journalctl -u demoapi -b-n 50看最近50行-f持续跟踪相当于tail -f--since按时间过滤-p err只看错误级别及以上-b限定本次开机以来的日志。实际排查里我用的最多的组合是-u 服务名 --since 5 min ago --no-pager因为刚操作完的日志最相关加--no-pager是为了避免输出被送进less导致脚本卡住。3.4 改配置后必做的daemon-reload这里单独强调一遍因为这是新手最容易漏的一步。修改unit文件后不执行daemon-reload你敲restart用的还是旧配置现象就是“明明改了却没生效”然后开始怀疑人生。一个更隐蔽的情况是EnvironmentFile指向的文件被修改。这种改动不需要daemon-reload因为文件是在每次启动服务时读取的但需要restart而不是reload才能让新变量生效。这两类改动要分清楚改动内容是否需要daemon-reload生效方式unit文件本身需要reload或restartEnvironmentFile文件不需要restart程序自己的配置文件不需要reload或restart依赖关系After/Wants需要restart判断标准很简单改动发生在systemd管辖的文件里就要daemon-reload改动发生在程序自己的地盘里就不用。3.5 停止、禁用、彻底清理的完整流程不用了的服务要清干净避免留下隐患。完整流程分四步sudo service demoapi stop sudo systemctl disable demoapi sudo rm /etc/systemd/system/demoapi.service sudo systemctl daemon-reload sudo systemctl reset-failed顺序不能乱。先停服务再禁用自启disable做的事就是删掉WantedBy对应的符号链接然后删unit文件再daemon-reload让systemd忘掉这个unit最后reset-failed清掉可能残留的失败状态记录。如果漏掉reset-failed之后创建同名unit时可能会看到奇怪的历史失败信息。4. 服务起不来怎么办排查思路与故障速查服务启动失败是最常见也最让人头疼的问题因为报错信息往往只有一句Job for xxx.service failed具体原因得自己挖。这一章按排查顺序来梳理照着走基本能定位到八成以上的问题。4.1 按顺序走的排查五步第一步看详细状态。service xxx status会给出失败原因的高亮行通常是Process: xxx ExecStart... (codeexited, status203/EXEC)这种格式括号里的状态码是核心线索。第二步看完整日志。journalctl -u xxx --since 5 min ago --no-pager重点看进程自己打印的错误比如“配置文件解析失败”“端口被占用”“权限不足”这类。这一步能解决大部分问题因为程序自己最清楚它为什么起不来。第三步手动执行一次。把unit里ExecStart那一行原样复制出来切换到User指定的账号手动跑一遍sudo -u appuser /usr/bin/python3 /opt/demoapi/app.py这一步的价值在于排除systemd的干扰直接看程序的行为。如果手动能跑起来说明问题出在环境环境变量、工作目录、权限上如果手动也报错那就是程序自身的问题跟systemd无关。第四步检查端口和资源。ss -lntp | grep 端口号看是不是被别的进程占了df -h看磁盘是不是满了free -m看内存。这几个基础检查经常能发现意外情况我就遇到过磁盘写满导致服务起不来的案例日志里完全没有相关提示只有程序莫名其妙退出。第五步检查依赖和顺序。如果服务依赖数据库、消息队列这类外部组件确认它们先起来了。用systemctl list-dependencies xxx可以看到依赖树。4.2 exit code对照表systemd的退出状态码有一套自己的编号体系和程序返回的普通退出码不是一回事。常见的几个整理如下状态码名称含义典型原因1FAILURE通用失败程序自身返回非02INVALIDARGUMENT参数无效ExecStart参数写错203EXEC执行失败路径不存在或无执行权限200CHDIR目录切换失败WorkingDirectory不存在217USER用户不存在User指定的账号没有209STDOUT标准输出重定向失败日志文件路径无权限226NAMESPACE命名空间设置失败沙箱相关配置有问题143-被SIGTERM终止通常是正常停止137-被SIGKILL终止被强制杀掉可能OOM看到203先查路径和权限看到217先查账号看到200先查工作目录这三个是最高频的。137要特别注意它往往意味着进程被系统的OOM Killer干掉了去看dmesg | grep -i killed process能确认。4.3 端口、权限、路径这三类高频坑端口占用的排查很直接。ss -lntp | grep 8080找出占用进程然后决定是改端口还是停掉占用者。有时候占用者是之前没清理干净的同名服务用systemctl status看到两个实例同时存在这种情况通常是旧的SysV脚本和新的systemd unit打架需要确认到底哪个在生效。权限问题花样最多。最典型的是三种一是unit文件本身权限不对如果/etc/systemd/system/xxx.service被设成600且属主不是rootsystemd读不到会报错二是User指定的账号没有读程序的权限比如程序放在/root下换个账号就访问不了三是程序需要访问某个目录但该目录权限没给够比如/var/log/xxx。这里有个容易被忽略的点ProtectSystem、PrivateTmp这类沙箱参数会影响程序的可见范围。如果你的unit加了PrivateTmptrue那么程序看到的/tmp是独立的它写到/tmp的文件在宿主机上找不到排查时会被误导。路径问题相对简单但要注意相对路径。ExecStart里所有路径都建议写绝对路径因为systemd不保证有PATH环境变量写python3可能报203写/usr/bin/python3才稳。4.4 不容易想到的坑与我的实操心得讲几个我踩过的、文档里不太会写的坑。第一个是StartLimitBurst触发的静默拒绝。systemd默认在10秒内允许一个服务启动5次超过之后会彻底拒绝报错是start request repeated too quickly。这时候Restartalways反而成了帮凶因为它会让服务不停重启直到触发限制。解决办法是systemctl reset-failed 服务名清掉计数同时把RestartSec调大或者配置StartLimitIntervalSec放宽[Unit] StartLimitIntervalSec60 StartLimitBurst10第二个是masked状态的迷惑性。有些服务会被包管理器或管理员主动屏蔽屏蔽的做法是把unit软链到/dev/null。这时候启动会报Unit is masked需要先sudo systemctl unmask 服务名。我在一台被前人动过的机器上找了半小时才想到去看这个状态。第三个是environment variable的继承问题。systemd启动的服务不会继承你shell里的环境变量所以你在终端里能跑通的命令放到unit里可能因为缺PATH或JAVA_HOME而失败。解决办法是在unit里显式声明或者用EnvironmentFile统一管理。第四个是关于reload的假成功。有些程序收到了SIGHUP但内部处理是异步的命令返回成功时配置还没真正生效。这种情况需要观察日志确认重载完成或者在重载后加几秒等待再验证。第五个是时间同步对服务的影响。如果机器时间不准涉及到证书校验或token验证的服务会莫名失败日志里报的是“证书过期”之类看着完全不像时间问题。排查这类问题前先跑一遍timedatectl确认时间同步状态。5. WSL、容器与批量场景下的服务管理差异前面讲的都是标准的物理机或虚拟机环境但实际工作里还有几种特殊环境服务管理方式差别不小不搞清楚会浪费很多时间。5.1 WSL里的systemd开启与差异在Windows上用WSL跑Ubuntu写代码的人越来越多这个环境跟原生Ubuntu最大的区别在于早期版本的WSL默认不启动systemdPID 1是微软自己的init进程所以service和systemctl都用不了会报找不到systemd。新版本WSL支持了systemd但需要手动开启。做法是在/etc/wsl.conf里加一段[boot] systemdtrue改完之后需要在Windows侧执行wsl --shutdown把整个WSL实例关掉再重进只关终端窗口是没用的。重启之后用systemctl is-system-running确认返回running就说明systemd接管成功了。WSL下的另一个差异是开机自启的意义不大。因为WSL实例是按需启动的你关掉所有终端窗口后实例可能还在后台跑也可能被回收。指望enable之后服务长期驻留并不靠谱更实际的做法是把启动命令写进shell的启动脚本或者用Windows侧的计划任务触发。5.2 容器里为什么不该用systemctl在Docker容器里跑Ubuntu镜像然后执行service nginx start大概率会碰到System has not been booted with systemd as init system这个报错。原因是容器里的PID 1通常是你指定的那个命令不是systemd所以没有systemd可以通信。容器场景下的正确思路是让业务进程直接作为PID 1运行比如CMD [nginx, -g, daemon off;]。这样做的好处有两点一是信号能正确传递docker stop发的SIGTERM能直接到达nginx主进程实现优雅退出二是容器生命周期清晰进程退出容器就停不需要额外的进程管理。如果确实需要在容器里用类似服务的操作可以用supervisord这类轻量进程管理器或者干脆在启动脚本里用加wait的方式管理多个进程。不要在容器里装systemd那是把简单问题复杂化。5.3 批量开关服务与定时重启的写法最后讲一个实际运维里经常遇到的需求一次操作多个服务。service命令一次只能处理一个但配合循环就很方便for svc in nginx redis mysql; do sudo service $svc restart echo $svc - $(systemctl is-active $svc) done这个写法比systemctl restart nginx redis mysql更可控因为重启是串行的能逐个确认状态出了问题也不会因为一个失败导致整批中断。定时重启是另一个常见需求通常是为了回收内存或避免长时间运行累积的资源泄漏。用systemd的timer比cron更合适因为timer能保证错过的时间点会补执行而且日志统一在journal里。写一个timer需要两个文件# /etc/systemd/system/demoapi-restart.service [Unit] DescriptionRestart demoapi periodically [Service] Typeoneshot ExecStart/usr/bin/systemctl restart demoapi# /etc/systemd/system/demoapi-restart.timer [Unit] DescriptionTimer for demoapi restart [Timer] OnCalendar*-*-* 04:00:00 Persistenttrue [Install] WantedBytimers.targetOnCalendar用的是systemd的时间格式Persistenttrue表示如果到了时间点机器正好关机下次开机后补执行一次。启用timer用systemctl enable --now demoapi-restart.timer查看下次触发时间用systemctl list-timers。注意定时重启只能缓解症状不能解决根因。如果服务需要靠定期重启才能稳定运行说明存在内存泄漏或句柄未释放的问题重启只是权宜之计真正的修复还得回到代码层面。我发现一个规律新手和熟手在服务管理上的差别往往不体现在命令敲得多熟而体现在出问题时能不能三分钟内定位到原因。这个能力来自对状态码、日志路径和启动链路的熟悉程度也来自踩坑的数量。上面这些排查思路和参数取值都不是拍脑袋写的是反复在生产环境里验证过、调整过的。你在自己的机器上动手写一个unit文件跑一遍把这些命令都过一遍手比看十篇文章都管用。 Ubuntu下service命令实战：systemd服务管理与故障排查
Service命令在Ubuntu日常运维里算是最容易被忽略、又最容易在关键时刻救命的一类工具。很多人装完系统之后一路用systemctl可一旦接手别人留下的老脚本、老文档或者在一台跑了好几年的服务器上排查问题时跳出来的还是service nginx start这种写法。这篇东西就是围绕Ubuntu下服务的启动、关闭、重启来展开把service命令的来龙去脉、它和systemctl的对应关系、自己写一个服务并托管给系统的完整流程以及各种起不来的排查思路全部讲透。不管你是刚装完Ubuntu的新手还是已经习惯敲systemctl的老手这里面的参数取舍逻辑和踩坑记录都值得花点时间看一看。1. 别急着敲service先把Ubuntu的服务管理机制摸清动手之前我先说一个现象同一个service nginx restart在不同版本的Ubuntu上跑出来的效果可能完全不一样有人执行完日志干净利落有人执行完等十几秒还没反应。原因不在命令本身而在于这条命令背后到底由谁在执行。1.1 service命令到底是什么它把活交给了谁service本身不是一个内核组件它是一个Shell脚本通常躺在/usr/sbin/service这个位置。它的工作模式非常朴素接收你给的服务名和动作名然后判断这个服务应该由谁来处理。判断逻辑大致分两层第一层看系统上跑的是不是systemd第二层看/etc/init.d/目录下有没有对应的SysV风格脚本。在Ubuntu 15.04之后的版本里systemd已经是默认的初始化系统所以绝大多数情况下你敲service nginx start脚本内部实际上会转成systemctl start nginx去执行。而在更老的Ubuntu 14.04上同样的命令会被翻译成/etc/init.d/nginx start。这就解释了一个常见困惑为什么有些教程里service和systemctl混着用也没出问题因为它们在systemd环境下本来就是同一件事的两种入口。理解这一点很重要它意味着你不需要把service和systemctl当成两套体系去学。真正决定服务行为的是systemd的unit文件而不是你敲的是哪个命令。1.2 为什么现在依然值得把service用熟既然service只是转发层直接学systemctl不就行了理论上没错但实际环境里service有几个无法替代的场景。第一个场景是老旧文档和自动化脚本的兼容。很多企业的部署脚本、Ansible playbook、Dockerfile里写的就是service xxx start这些脚本可能跨Ubuntu、Debian、CentOS多个发行版跑用service能获得更好的兼容性因为它在Debian系和RHEL系上都存在。第二个场景是肌肉记忆和简洁性。service这个词更短语义更直白在需要快速敲命令的场合service mysql restart比systemctl restart mysql少敲好几个字符。这不是小事一天执行几十次的时候差别很明显。第三个场景是SysV脚本的兜底。有些第三方软件安装时只提供/etc/init.d/下的传统脚本没有systemd unit这时候只有service能顺畅调用它们systemctl会直接报找不到unit。提示如果service报出Unit xxx.service not found说明这个服务没有systemd unit可以去看/etc/init.d/目录下是否存在同名脚本。反过来如果systemctl找不到而service能跑通基本可以确定这是一个纯SysV脚本。1.3 动手前必须先建立的三个认知在开始敲命令之前有三个概念如果不建立起来后面排查问题会处处被动。第一服务的状态不是二元的。除了“运行中”和“已停止”还有activating正在启动、deactivating正在停止、failed启动失败、masked被屏蔽。很多人看到systemctl status输出里写着inactive (dead)就以为服务没启动过其实dead只是当前状态描述不代表历史上有过失败。第二服务名和进程名不一定一致。服务名是unit的名字比如nginx.service而它启动的实际进程可能叫nginx也可能是nginx: master process。反过来有些程序一个unit里会拉起好几个进程比如带worker的模型。排查的时候不要拿ps的输出直接和服务名对比。第三systemd会记住服务的失败状态。一个服务连续启动失败超过阈值之后会被标记为failed并且拒绝再次启动这时候你反复敲start都没用必须先reset-failed。这一点后面在排查章节会详细展开很多人第一次遇到会一脸懵。2. service命令的四类操作与参数细节命令本身的语法非常统一service 服务名 动作。动作就那么几个但每个动作背后的行为差异不小尤其是重启这一类选错了会造成连接中断或者配置没生效。2.1 启动服务start以及它返回0不代表真的起来了启动服务最常用的写法是sudo service nginx start这里的sudo不能省。原因是systemd的启动操作需要和PID 1通信普通用户没有权限会直接报Failed to start nginx.service: Interactive authentication required。执行完成之后命令返回退出码0很多人就此认为服务已经跑起来了。这是一个典型的误区。在systemd下start命令是同步等待unit进入active状态的如果unit的Typesimple那么只要进程被fork出来systemd就认为启动成功至于进程在之后0.5秒内崩溃退出start命令是不会报错的。也就是说退出码0只代表“启动动作被接受了”不代表“服务处于健康运行状态”。想确认真的起来了你需要紧接着执行service nginx status或者用systemctl is-active nginx看一眼返回值。我习惯的做法是启动后立刻查一次状态如果是生产环境的批量脚本还会加一个循环等待最多等10秒确认端口开始监听。sudo service nginx start sleep 1 systemctl is-active --quiet nginx echo 已运行 || echo 启动异常对于Typeforking的服务start的语义又不一样systemd会等待主进程fork完成并且父进程退出后才算启动成功。所以同样一条start不同unit类型下的等待时间差别很大这解释了为什么有些服务敲完立刻返回有些会卡住一两秒。2.2 关闭服务stop与真实退出时间关闭服务用sudo service nginx stop。这里的坑主要在两个地方一是服务可能关不干净二是关闭过程可能非常慢。先说不干净。systemd默认发送的是SIGTERM信号也就是让进程优雅退出释放资源、写完缓冲区、关闭连接。大部分写得规范的守护进程收到这个信号会主动退出。但有些老程序只处理SIGINT或干脆没有任何信号处理逻辑那么SIGTERM会被忽略进程继续活在内存里。systemd等一段时间后默认90秒DefaultTimeoutStopSec会发送SIGKILL强制杀掉。在这段时间里service stop这条命令是一直阻塞的不会返回。再说慢。如果你发现service stop敲下去之后光标不动了十几秒八成是程序在等待正在处理的请求完成或者卡在某个网络超时上。这种情况下的调优思路是在unit文件里显式声明超时时间而不是干等默认的90秒[Service] TimeoutStopSec15 KillSignalSIGTERM KillModemixedTimeoutStopSec设多少合适取决于业务本身。我的经验算法是先测出正常情况下优雅退出的耗时再乘以2.5到3倍作为缓冲。比如实测平均3秒退出最长一次8秒那就设20秒。给得太短会导致请求被强杀丢数据给得太长会导致发布流程卡顿20秒是个比较舒服的平衡点。KillMode这个参数值得单独说一下。默认值是control-group意思是停止服务时把整个cgroup里的所有进程全部杀掉包括主进程拉起来的子进程。改成mixed的话主进程收到SIGTERM子进程收到SIGKILL适合那种主进程需要感知子进程退出并做清理的场景。反过来如果你的服务是用shell脚本包装启动的主进程其实是个脚本真正的业务进程是它的子进程那可能更适合process模式只杀主进程而让业务进程自行处理。2.3 重启与重载restart、reload、try-restart怎么选这是最容易出错的一组命令因为它们的名字很像效果差别却很大。restart是停止加启动会完整地断开所有连接再重新建立。对于Nginx这种前置网关restart会有短暂的窗口期正在处理的请求可能被中断。对于数据库这类有连接池的服务重启意味着所有客户端连接全部掉线需要重连。所以restart不是默认选择它应该是配置改动比较大、必须重新加载进程结构时才用。reload是向服务发送重载信号通常是SIGHUP让进程重新读取配置文件而不退出。比如Nginx的reload可以做到零中断地应用新的虚拟主机配置因为master进程会先校验新配置再平滑地把worker换掉。但reload有个前提服务本身必须实现ExecReload否则systemd会直接报错。[Service] ExecReload/bin/kill -HUP $MAINPID$MAINPID是systemd提供的变量指向服务的主进程号。如果你的服务文档说支持SIGHUP热加载就需要在unit里配上这一行service xxx reload才能工作。try-restart是只在服务已经运行的情况下才重启如果当前是停止状态就直接返回成功。这个动作在批量运维里非常好用可以避免把本来就没开着的服务意外启动起来。reload-or-restart则是一个智能兜底优先尝试reloadreload失败服务不支持就退化成restart。我把这四个动作的行为整理成一张表方便对照动作是否中断连接是否需要ExecReload典型使用场景restart是否配置结构变化、升级二进制reload否是只改配置内容、加虚拟主机try-restart是否批量操作中避免误启动reload-or-restart视情况否不想判断服务是否支持reload注意reload不生效时不要反复重试。有些服务的reload只是读一遍配置但不做校验配错了也不会报错直到下一次请求进来才暴露问题。改完配置后建议先跑一次配置校验命令比如nginx -t再执行reload。2.4 status与--status-all输出到底该怎么读service nginx status的输出本质上就是systemctl status nginx的结果分几块内容我按重要性排个序。第一块是加载路径也就是Loaded:这一行它会告诉你unit文件的位置以及是否被enable。如果后面跟着disabled说明服务不会开机自启。如果显示masked说明这个服务被屏蔽了任何启动操作都会被拒绝需要先unmask。第二块是Active:这一行格式是Active: active (running) since 时间。这里最容易让人困惑的是括号里的状态描述常见的有running、exited、dead、failed。exited表示进程已经正常退出对于一次性任务型的unit是正常状态对于常驻服务就说明它挂了。第三块是Main PID和CGroup这两行在排查权限和资源问题时很有用能看到实际运行的进程号和它所属的控制组。第四块是最近几行日志通常只有5到10行够做初步判断但要完整日志还是得用journalctl。至于service --status-all这个命令会遍历/etc/init.d/下的所有脚本并逐个查询状态输出形如[ ] cron [ - ] nginx [ ? ] myservice方括号里的符号含义要记清楚表示运行中-表示已停止?表示状态未知。?出现的原因是脚本没有实现标准的status动作systemd无法判断它的状态这种情况需要单独去看进程和端口。这里有个实际经验--status-all执行速度取决于系统上有多少init脚本脚本多的时候可能要等十几秒。另外这个命令只覆盖/etc/init.d/纯systemd unit不会被列出来。想看全部服务状态用systemctl list-units --typeservice更全面。2.5 命令对照速查表把两套命令放一起对照用哪个都不会迷路操作service写法systemctl写法启动service nginx startsystemctl start nginx关闭service nginx stopsystemctl stop nginx重启service nginx restartsystemctl restart nginx重载service nginx reloadsystemctl reload nginx查状态service nginx statussystemctl status nginx是否运行无直接写法systemctl is-active nginx是否自启无直接写法systemctl is-enabled nginx全部状态service --status-allsystemctl list-units --typeservice可以看出来service覆盖的是最常用的几个动作而开关机自启这类配置性的操作只能走systemctl。所以现实中的正确姿势是日常启停用service图省事涉及配置和查询用systemctl。3. 从零跑通一遍写一个自己的服务并托管给systemd光看命令容易记不住最好的办法是拿一个自己的小程序从头到尾托管给系统跑一遍。下面用一个简单的Python HTTP服务做例子这个例子足够小能看懂又足够真实包含了账号、工作目录、环境变量这些实际项目里的要素。3.1 准备程序与运行账号先说账号。绝对不要用root跑业务服务这是硬规矩。原因很直接一旦服务被利用攻击者拿到的就是root权限整个机器就交代了。正确的做法是创建一个专用的系统账号没有登录shell没有家目录只用来跑服务。sudo useradd --system --no-create-home --shell /usr/sbin/nologin appuser sudo mkdir -p /opt/demoapi sudo chown -R appuser:appuser /opt/demoapi--system表示创建系统账号UID会在系统账号范围内分配--no-create-home是因为服务不需要家目录省得多出一个无用目录--shell /usr/sbin/nologin保证这个账号无法登录即使有人拿到了密码也没用。然后是程序本身放在/opt/demoapi/app.py内容简单到不行就是监听一个端口from http.server import BaseHTTPRequestHandler, HTTPServer import os PORT int(os.environ.get(PORT, 8080)) class Handler(BaseHTTPRequestHandler): def do_GET(self): self.send_response(200) self.send_header(Content-Type, text/plain; charsetutf-8) self.end_headers() self.wfile.write(bdemo api is running\n) def log_message(self, fmt, *args): print(%s - %s % (self.address_string(), fmt % args)) if __name__ __main__: HTTPServer((0.0.0.0, PORT), Handler).serve_forever()这里特意从环境变量读端口目的是后面演示Environment参数怎么用。日志直接打到标准输出交给journald收集这也是systemd下最推荐的做法不要自己往文件里写日志。3.2 unit文件逐段拆解与参数计算unit文件放在/etc/systemd/system/demoapi.service。为什么放这里而不是/lib/systemd/system/因为/lib/systemd/system/是软件包安装的位置系统升级或重装包的时候可能被覆盖/etc/systemd/system/的优先级更高且属于管理员的地盘不会被包管理动到。完整内容如下[Unit] DescriptionDemo API Service Documentationhttps://example.internal/demoapi Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple Userappuser Groupappuser WorkingDirectory/opt/demoapi EnvironmentPORT8080 EnvironmentFile-/etc/demoapi/env ExecStart/usr/bin/python3 /opt/demoapi/app.py ExecReload/bin/kill -HUP $MAINPID Restarton-failure RestartSec5 TimeoutStopSec20 KillSignalSIGTERM SuccessExitStatus143 StandardOutputjournal StandardErrorjournal LimitNOFILE65535 [Install] WantedBymulti-user.target逐段说清楚每个选项为什么这么写。Afternetwork-online.target和Wantsnetwork-online.target是配对使用的。After只控制启动顺序意思是网络在线之后再启动本服务Wants才是真正把network-online.target拉进来作为依赖。很多人只写After不写Wants结果发现服务启动时网络还没就绪连接外部依赖直接失败。这里用Wants而不是Requires是因为网络目标即使启动失败也不应该阻止本服务尝试启动用弱依赖更合理。Typesimple是默认值表示ExecStart启动的就是主进程systemd认为进程一fork出来服务就算起来了。这个类型适合前台运行的常驻程序。如果程序会自己daemonize就要改成Typeforking并配合PIDFile。Environment和EnvironmentFile的区别值得说一下。前者适合写少量固定值直接内联在unit里后者适合放敏感配置比如数据库密码把文件权限设成600只有root能读避免密码出现在unit文件里被随便查看。注意EnvironmentFile-前面那个减号它的含义是“文件不存在也不报错”这个设计对多环境部署很实用测试环境可以没有这个文件。Restarton-failure的含义是只有非正常退出才重启正常退出exit code 0不重启。其他可选值里always是无论怎么退出都重启适合那种绝对不能停的服务但要小心配错配置导致无限重启循环no是默认值不自动重启。RestartSec5这个值的计算有讲究。设太短服务因为依赖的下游没起来而崩溃systemd会疯狂重启日志被刷爆CPU也被吃掉设太长恢复时间变慢。我的经验是先用5秒起步观察journal日志里的重启频率如果发现30秒内重启超过3次说明问题不在重启策略上而是服务本身有问题先修问题再调参数。SuccessExitStatus143这一行容易被忽略。143是128加15代表进程被SIGTERM终止。默认情况下systemd认为收到信号退出是失败这会触发Restarton-failure导致重启循环。把143声明为成功退出码可以避免停止服务时被误判为崩溃。类似的还有130SIGINT等按实际需要加。LimitNOFILE65535是文件描述符上限。这个值的来路可以简单估算假设单实例每秒处理3000个请求每个连接平均存活0.5秒那么瞬时并发连接约1500个每个连接至少占一个fd再加上日志文件、socket、内部句柄65535这个量级留了充足余量。如果是高并发网关可能要调到六位数但要注意系统级fs.file-max也得同步放开。StandardOutputjournal表示日志交给journald这是systemd环境下的标准做法。好处是日志有统一的索引和轮转可以用journalctl -u按服务名过滤也能设总量上限避免把磁盘写满。WantedBymulti-user.target决定了systemctl enable时会创建什么符号链接。multi-user.target是常规的多用户命令行模式绝大多数服务都挂在这里。如果是图形界面相关的服务才需要考虑graphical.target。3.3 装载、启动、验证、看日志unit文件写完之后第一件事不是启动而是让systemd重新读取配置sudo systemctl daemon-reload这个命令的作用是重新扫描所有unit文件并重建依赖树。刚创建的unit文件如果不执行这一步systemctl是看不到它的会直接报Unit not found。同样的道理任何对unit文件的修改包括改环境变量、改启动命令、改依赖关系都需要重新执行一次daemon-reload。接下来是启动和验证sudo service demoapi start sudo service demoapi status如果状态显示active (running)再用端口确认一遍ss -lntp | grep 8080 curl -s http://127.0.0.1:8080ss -lntp里的参数含义是-l只看监听状态、-n不解析服务名、-t只看TCP、-p显示进程。这四条组合起来是排查端口问题的标准起手式。如果这里看不到8080那说明服务没真正监听前端再怎么配也没用。看日志用journalctl最常用的几种查法sudo journalctl -u demoapi -n 50 --no-pager sudo journalctl -u demoapi -f sudo journalctl -u demoapi --since 10 min ago -p err sudo journalctl -u demoapi -b-n 50看最近50行-f持续跟踪相当于tail -f--since按时间过滤-p err只看错误级别及以上-b限定本次开机以来的日志。实际排查里我用的最多的组合是-u 服务名 --since 5 min ago --no-pager因为刚操作完的日志最相关加--no-pager是为了避免输出被送进less导致脚本卡住。3.4 改配置后必做的daemon-reload这里单独强调一遍因为这是新手最容易漏的一步。修改unit文件后不执行daemon-reload你敲restart用的还是旧配置现象就是“明明改了却没生效”然后开始怀疑人生。一个更隐蔽的情况是EnvironmentFile指向的文件被修改。这种改动不需要daemon-reload因为文件是在每次启动服务时读取的但需要restart而不是reload才能让新变量生效。这两类改动要分清楚改动内容是否需要daemon-reload生效方式unit文件本身需要reload或restartEnvironmentFile文件不需要restart程序自己的配置文件不需要reload或restart依赖关系After/Wants需要restart判断标准很简单改动发生在systemd管辖的文件里就要daemon-reload改动发生在程序自己的地盘里就不用。3.5 停止、禁用、彻底清理的完整流程不用了的服务要清干净避免留下隐患。完整流程分四步sudo service demoapi stop sudo systemctl disable demoapi sudo rm /etc/systemd/system/demoapi.service sudo systemctl daemon-reload sudo systemctl reset-failed顺序不能乱。先停服务再禁用自启disable做的事就是删掉WantedBy对应的符号链接然后删unit文件再daemon-reload让systemd忘掉这个unit最后reset-failed清掉可能残留的失败状态记录。如果漏掉reset-failed之后创建同名unit时可能会看到奇怪的历史失败信息。4. 服务起不来怎么办排查思路与故障速查服务启动失败是最常见也最让人头疼的问题因为报错信息往往只有一句Job for xxx.service failed具体原因得自己挖。这一章按排查顺序来梳理照着走基本能定位到八成以上的问题。4.1 按顺序走的排查五步第一步看详细状态。service xxx status会给出失败原因的高亮行通常是Process: xxx ExecStart... (codeexited, status203/EXEC)这种格式括号里的状态码是核心线索。第二步看完整日志。journalctl -u xxx --since 5 min ago --no-pager重点看进程自己打印的错误比如“配置文件解析失败”“端口被占用”“权限不足”这类。这一步能解决大部分问题因为程序自己最清楚它为什么起不来。第三步手动执行一次。把unit里ExecStart那一行原样复制出来切换到User指定的账号手动跑一遍sudo -u appuser /usr/bin/python3 /opt/demoapi/app.py这一步的价值在于排除systemd的干扰直接看程序的行为。如果手动能跑起来说明问题出在环境环境变量、工作目录、权限上如果手动也报错那就是程序自身的问题跟systemd无关。第四步检查端口和资源。ss -lntp | grep 端口号看是不是被别的进程占了df -h看磁盘是不是满了free -m看内存。这几个基础检查经常能发现意外情况我就遇到过磁盘写满导致服务起不来的案例日志里完全没有相关提示只有程序莫名其妙退出。第五步检查依赖和顺序。如果服务依赖数据库、消息队列这类外部组件确认它们先起来了。用systemctl list-dependencies xxx可以看到依赖树。4.2 exit code对照表systemd的退出状态码有一套自己的编号体系和程序返回的普通退出码不是一回事。常见的几个整理如下状态码名称含义典型原因1FAILURE通用失败程序自身返回非02INVALIDARGUMENT参数无效ExecStart参数写错203EXEC执行失败路径不存在或无执行权限200CHDIR目录切换失败WorkingDirectory不存在217USER用户不存在User指定的账号没有209STDOUT标准输出重定向失败日志文件路径无权限226NAMESPACE命名空间设置失败沙箱相关配置有问题143-被SIGTERM终止通常是正常停止137-被SIGKILL终止被强制杀掉可能OOM看到203先查路径和权限看到217先查账号看到200先查工作目录这三个是最高频的。137要特别注意它往往意味着进程被系统的OOM Killer干掉了去看dmesg | grep -i killed process能确认。4.3 端口、权限、路径这三类高频坑端口占用的排查很直接。ss -lntp | grep 8080找出占用进程然后决定是改端口还是停掉占用者。有时候占用者是之前没清理干净的同名服务用systemctl status看到两个实例同时存在这种情况通常是旧的SysV脚本和新的systemd unit打架需要确认到底哪个在生效。权限问题花样最多。最典型的是三种一是unit文件本身权限不对如果/etc/systemd/system/xxx.service被设成600且属主不是rootsystemd读不到会报错二是User指定的账号没有读程序的权限比如程序放在/root下换个账号就访问不了三是程序需要访问某个目录但该目录权限没给够比如/var/log/xxx。这里有个容易被忽略的点ProtectSystem、PrivateTmp这类沙箱参数会影响程序的可见范围。如果你的unit加了PrivateTmptrue那么程序看到的/tmp是独立的它写到/tmp的文件在宿主机上找不到排查时会被误导。路径问题相对简单但要注意相对路径。ExecStart里所有路径都建议写绝对路径因为systemd不保证有PATH环境变量写python3可能报203写/usr/bin/python3才稳。4.4 不容易想到的坑与我的实操心得讲几个我踩过的、文档里不太会写的坑。第一个是StartLimitBurst触发的静默拒绝。systemd默认在10秒内允许一个服务启动5次超过之后会彻底拒绝报错是start request repeated too quickly。这时候Restartalways反而成了帮凶因为它会让服务不停重启直到触发限制。解决办法是systemctl reset-failed 服务名清掉计数同时把RestartSec调大或者配置StartLimitIntervalSec放宽[Unit] StartLimitIntervalSec60 StartLimitBurst10第二个是masked状态的迷惑性。有些服务会被包管理器或管理员主动屏蔽屏蔽的做法是把unit软链到/dev/null。这时候启动会报Unit is masked需要先sudo systemctl unmask 服务名。我在一台被前人动过的机器上找了半小时才想到去看这个状态。第三个是environment variable的继承问题。systemd启动的服务不会继承你shell里的环境变量所以你在终端里能跑通的命令放到unit里可能因为缺PATH或JAVA_HOME而失败。解决办法是在unit里显式声明或者用EnvironmentFile统一管理。第四个是关于reload的假成功。有些程序收到了SIGHUP但内部处理是异步的命令返回成功时配置还没真正生效。这种情况需要观察日志确认重载完成或者在重载后加几秒等待再验证。第五个是时间同步对服务的影响。如果机器时间不准涉及到证书校验或token验证的服务会莫名失败日志里报的是“证书过期”之类看着完全不像时间问题。排查这类问题前先跑一遍timedatectl确认时间同步状态。5. WSL、容器与批量场景下的服务管理差异前面讲的都是标准的物理机或虚拟机环境但实际工作里还有几种特殊环境服务管理方式差别不小不搞清楚会浪费很多时间。5.1 WSL里的systemd开启与差异在Windows上用WSL跑Ubuntu写代码的人越来越多这个环境跟原生Ubuntu最大的区别在于早期版本的WSL默认不启动systemdPID 1是微软自己的init进程所以service和systemctl都用不了会报找不到systemd。新版本WSL支持了systemd但需要手动开启。做法是在/etc/wsl.conf里加一段[boot] systemdtrue改完之后需要在Windows侧执行wsl --shutdown把整个WSL实例关掉再重进只关终端窗口是没用的。重启之后用systemctl is-system-running确认返回running就说明systemd接管成功了。WSL下的另一个差异是开机自启的意义不大。因为WSL实例是按需启动的你关掉所有终端窗口后实例可能还在后台跑也可能被回收。指望enable之后服务长期驻留并不靠谱更实际的做法是把启动命令写进shell的启动脚本或者用Windows侧的计划任务触发。5.2 容器里为什么不该用systemctl在Docker容器里跑Ubuntu镜像然后执行service nginx start大概率会碰到System has not been booted with systemd as init system这个报错。原因是容器里的PID 1通常是你指定的那个命令不是systemd所以没有systemd可以通信。容器场景下的正确思路是让业务进程直接作为PID 1运行比如CMD [nginx, -g, daemon off;]。这样做的好处有两点一是信号能正确传递docker stop发的SIGTERM能直接到达nginx主进程实现优雅退出二是容器生命周期清晰进程退出容器就停不需要额外的进程管理。如果确实需要在容器里用类似服务的操作可以用supervisord这类轻量进程管理器或者干脆在启动脚本里用加wait的方式管理多个进程。不要在容器里装systemd那是把简单问题复杂化。5.3 批量开关服务与定时重启的写法最后讲一个实际运维里经常遇到的需求一次操作多个服务。service命令一次只能处理一个但配合循环就很方便for svc in nginx redis mysql; do sudo service $svc restart echo $svc - $(systemctl is-active $svc) done这个写法比systemctl restart nginx redis mysql更可控因为重启是串行的能逐个确认状态出了问题也不会因为一个失败导致整批中断。定时重启是另一个常见需求通常是为了回收内存或避免长时间运行累积的资源泄漏。用systemd的timer比cron更合适因为timer能保证错过的时间点会补执行而且日志统一在journal里。写一个timer需要两个文件# /etc/systemd/system/demoapi-restart.service [Unit] DescriptionRestart demoapi periodically [Service] Typeoneshot ExecStart/usr/bin/systemctl restart demoapi# /etc/systemd/system/demoapi-restart.timer [Unit] DescriptionTimer for demoapi restart [Timer] OnCalendar*-*-* 04:00:00 Persistenttrue [Install] WantedBytimers.targetOnCalendar用的是systemd的时间格式Persistenttrue表示如果到了时间点机器正好关机下次开机后补执行一次。启用timer用systemctl enable --now demoapi-restart.timer查看下次触发时间用systemctl list-timers。注意定时重启只能缓解症状不能解决根因。如果服务需要靠定期重启才能稳定运行说明存在内存泄漏或句柄未释放的问题重启只是权宜之计真正的修复还得回到代码层面。我发现一个规律新手和熟手在服务管理上的差别往往不体现在命令敲得多熟而体现在出问题时能不能三分钟内定位到原因。这个能力来自对状态码、日志路径和启动链路的熟悉程度也来自踩坑的数量。上面这些排查思路和参数取值都不是拍脑袋写的是反复在生产环境里验证过、调整过的。你在自己的机器上动手写一个unit文件跑一遍把这些命令都过一遍手比看十篇文章都管用。