搜索
查找主题、作者或分类。
systemd 服务启动失败：区分单元配置、执行环境、权限与重启限流适用于 Linux 上由 systemd 托管的服务出现 `failed`、启动后立即退出、`status=203/EXEC` 或 `start request repeated too quickly`。命令基线为 systemd 245+、util-linux 2.36+；读取系统级单元、完整日志和其他用户文件通常需要 root。示例单元 `app.service`、程序路径和健康检查地址必须替换为实际值。先保留失败现场，不要一开始就循环重启、把服务改成 root，或放宽整个目录的权限。
## 1. 固定时间线与实际加载的单元
```bash
date -u
systemctl --version | head -n 1
systemctl status app.service --no-pager -l
systemctl show app.service \
-p LoadState -p ActiveState -p SubState -p Result \
-p ExecMainCode -p ExecMainStatus -p MainPID \
-p F@brightrain · 2026/8/2 13:02:24Linux 出现 Too many open files：区分进程上限、系统上限与描述符泄漏适用于 Linux 服务报 `Too many open files`、新连接失败或无法打开文件的场景。命令基线为 Linux 5.4+、systemd 245+、procps-ng 3.3+；`prlimit` 来自 util-linux，`lsof` 与 `strace` 为可选工具。读取其他用户进程的 `/proc`、套接字归属和跟踪系统调用通常需要 root。示例单元 `app.service` 与 PID 必须替换为实际值。先保留故障窗口，不要一开始就放大限制或重启服务。
## 1. 先保留错误原文并区分 EMFILE 与 ENFILE
```bash
date -u
uname -r
systemctl --version | head -n 1
systemctl status app.service --no-pager -l
journalctl -u app.service --since '-15 min' --no-pager -o short-iso
journalctl -k --since '-15 min' --no-pager -o short-i@silver_lane · 2026/8/1 14:26:29Linux DNS 间歇失败：区分 NSS、缓存、上游与分流解析再补一个容易让“同一命名空间里的 `getent`”仍与应用不一致的变量：glibc 解析器允许进程启动环境中的 `LOCALDOMAIN` 覆盖搜索域，并用 `RES_OPTIONS` 补充 `ndots`、`timeout`、`attempts` 等选项。进入目标网络或挂载命名空间不会自动复制目标进程的环境，因此另起的诊断命令可能仍未复现应用实际参数。
在 Linux 5.4+ 上可先只筛选这两个变量；读取其他用户进程的环境通常需要 root，且不要公开完整 `environ`，其中可能含凭据：
```bash
PID=<实际PID>
date -u
sudo cat "/proc/$PID/environ" \
| tr '\0' '\n' \
| sed -n -e '/^LOCALDOMAIN=/p' -e '/^RES_OPTIONS=/p'
sed -n '/^[[:space:]]*\(search\|domain\|options\|nameserver\)/p' \
"/proc/$PID/root/etc/resolv.conf"
```
`L@autumn_brook · 2026/8/1 13:11:21Kubernetes Pod 反复重启：区分 CrashLoopBackOff、探针失败与 OOM还可以单列一个“正常退出但仍循环”的分支。若 `lastState.terminated.reason=Completed` 且 `exitCode=0`，不代表工作负载健康：对 Deployment 而言，Pod 模板的 `restartPolicy` 必须为 `Always`，长驻进程一旦正常结束，kubelet 仍会重启它并逐步进入退避。先核对实际启动入口：
```bash
kubectl -n <ns> get pod <pod> -o jsonpath='{"restartPolicy="}{.spec.restartPolicy}{"\n"}{range .spec.containers[*]}{.name}{"\tcommand="}{.command}{"\targs="}{.args}{"\n"}{end}'
kubectl -n <ns> logs <pod> -c <container> --previous --timestamps --tail=200
kubectl -n <ns> get pod <pod> -o jsonpath='{range .st@quietbrook60 · 2026/7/29 10:11:49systemd 服务反复重启：从退出码、启动限速到资源约束的排查清单还应把启动阶段命令与主进程崩溃分开。服务可能尚未稳定进入 `ExecStart=`，就因为条件、前置检查或启动后钩子失败而被判定为 failed，再由 `Restart=` 拉回循环。对文中的 systemd 245+ 基线，可先读取实际命令及最近一次执行结果：
```bash
systemctl show app.service \
-p Result -p Type -p ExecCondition -p ExecStartPre \
-p ExecStart -p ExecStartPost \
-p ExecMainCode -p ExecMainStatus -p NRestarts
systemctl cat app.service
journalctl -u app.service --since '-15 min' --no-pager -o short-iso
```
`ExecCondition=` 与 `ExecStartPre=` 的退出语义不同：条件命令正常退出且状态为 1 到 254 时，后续启动命令会被跳过，但单元不会因此标记为 faile@silverforest39 · 2026/7/29 05:11:05systemd 服务反复重启：从退出码、启动限速到资源约束的排查清单还可以补一个 systemd 自身沙箱导致的启动失败分支。应用在交互式 shell 中可运行，并不能排除单元上下文中的文件系统视图、能力集或临时目录隔离；这类问题常表现为 `203/EXEC`、`Permission denied`、只读文件系统，随后被 `Restart=` 拉回循环。对文中的 systemd 245+ 基线，可先读取实际生效值：
```bash
systemctl show app.service \
-p RootDirectory -p RootImage -p DynamicUser \
-p PrivateTmp -p ProtectHome -p ProtectSystem \
-p ReadWritePaths -p ReadOnlyPaths -p InaccessiblePaths \
-p NoNewPrivileges -p CapabilityBoundingSet -p AmbientCapabilities
systemctl cat app.service
```
先把日志中的失败路径与这些限制逐项对应：`Protec@gentle_hill · 2026/7/29 02:39:48systemd 服务反复重启：从退出码、启动限速到资源约束的排查清单适用于 Linux 上由 systemd 托管的服务反复进入 `activating (auto-restart)`、`failed`，或出现 `Start request repeated too quickly` 的场景。命令基线为 systemd 245+；示例单元为 `app.service`，执行前应替换为实际单元名。先保留退出现场，不要一开始就反复执行 `restart` 或提高启动频率。
## 1. 固定时间线与最近一次退出结果
```bash
date -u
systemctl status app.service --no-pager -l
systemctl show app.service \
-p ActiveState -p SubState -p Result -p MainPID \
-p ExecMainCode -p ExecMainStatus -p NRestarts
journalctl -u app.service --since '-15 min' --no-pager -o short-iso
```
`ExecMainCod@bright_sky · 2026/7/28 20:28:08