WorkingDirectory 指定服务进程启动时的工作目录，决定相对路径解析、模块加载基准、日志/临时文件生成位置及安全沙盒范围；必须为存在的绝对路径，运行用户需有rx权限，支持%h %u等变量扩展。

WorkingDirectory 是 systemd 服务中一个看似简单但极易出错的关键配置项。它不是可选项，而是决定服务能否正确读取配置、加载模块、写入日志的执行基础。

WorkingDirectory 的核心作用

它指定了服务进程启动时的当前工作目录（即 shell 中的 cd 目标路径），直接影响：

• 所有相对路径的解析起点（如 ./config.yaml、logs/app.log）
• Node.js 的 require() 或 Python 的 import 查找路径基准
• 服务默认生成临时文件、日志、PID 文件的位置（除非命令中显式指定绝对路径）
• 配合 ProtectSystem=strict 等安全选项，限制服务对文件系统的实际访问范围

必须遵守的配置规则

这条指令看似只写一行路径，但有四个硬性要求，缺一不可：

• 必须是绝对路径：不能用 ~、./ 或 ../；例如 /opt/myapp ✅，~/myapp ❌
• 目录必须预先存在：systemd 启动时不会自动创建该目录，不存在则服务直接失败（failed with result 'start-limit-hit'）
• 运行用户必须有读+执行权限（rx）：否则报 Permission denied；若需写入，还需 w 权限
• 支持有限变量扩展：如 %h（用户家目录）、%u（用户名），但仅在路径中有效，且变量展开后仍须满足上述三条

典型配置写法与常见错误

正确示例：

[Service]
User=webapp
WorkingDirectory=/var/www/myproject
ExecStart=/usr/bin/npm start

此时 npm start 会在 /var/www/myproject 下执行，能正常读取 package.json 和 .env。

tailwind-design-system

使用Tailwind CSS、设计令牌、组件库和响应式模式构建可扩展的设计系统。在创建组件库、实现设计系统或标准化UI模式时使用。

下载

错误写法举例：

• WorkingDirectory=../myapp —— 相对路径，systemd 拒绝加载
• WorkingDirectory=/srv/app 但该目录未创建或属主不是 webapp —— 启动卡在 activating (auto-restart)
• WorkingDirectory=/home/%u/app 用于系统级服务（User=root）—— %u 展开为 root，但 /home/root 可能无执行权限或不符合最小权限原则

验证和调试方法

配置完成后，别急着启用，先做三步检查：

• 手动模拟：用服务用户身份执行 sudo -u webapp ls -ld /var/www/myproject，确认目录存在且可进入
• 加载并检查语法：sudo systemctl daemon-reload && sudo systemctl cat myapp.service | grep WorkingDirectory
• 启动后查实际工作目录：sudo systemctl status myapp.service 看是否报错；再查进程：sudo cat /proc/$(pidof node)/cwd（替换为你的主进程名），输出应为配置的绝对路径