1. 项目概述这不是一次普通安装而是一次环境可信链的重建“第二章环境准备与安装部署”——光看标题你可能以为这只是教程里最不起眼的铺垫章节。但在我过去十年带团队落地过37个边缘AI代理系统、12个车载中间件平台、8个工业协议网关项目的实操经验里所有后期出现的90%以上诡异故障根源都埋在这“第二章”里。不是代码写错了而是环境没立住不是逻辑不严谨而是PATH没导对不是服务起不来而是systemd根本没真正接管进程。OpenClaw不是个玩具CLI工具它是个需要严格运行时契约的智能体运行时Agent Runtime而Node.js版本、nvm的shell初始化时机、systemd的启动上下文、Ubuntu的init系统模式——这四者一旦错位你得到的将是一个永远在“command not found”和“no installations recognized”之间循环的幽灵进程。我今天要讲的不是照着官网复制粘贴的安装流水账。我要带你拆开这四个关键词背后的真实约束条件为什么OpenClaw硬性要求Node 24不是因为新特性炫酷而是V8引擎对WebAssembly线程模型的底层支持变更为什么nvm在WSL或VMware虚拟机里常失效不是脚本有问题而是.bashrc和.profile的加载顺序在不同登录场景下存在不可见的执行断层为什么system has not been booted with systemd as init system这个报错会卡死整个部署因为它暴露的是Ubuntu镜像底层init机制的“身份认知错乱”——你用的是systemd的语法但内核启动时喂给它的却是sysvinit的PID 1。这些细节官方文档不会写Stack Overflow的答案往往治标不治本而你一旦跳过它们直接跑openclaw start后面花三天排查一个PATH问题远比花三十分钟把环境底座夯实在一开始更伤元气。这篇文章面向三类人一是刚从Windows转Linux、对shell生命周期还停留在“打开终端就等于环境就绪”阶段的新手二是正在NAS、RK3588开发板或Docker容器里部署OpenClaw却反复遭遇openclaw: command not found的实战派三是已经能跑通但总在升级Node后发现nvm use 24成功却node -v仍显示旧版的进阶用户。全文不讲虚的每一个命令、每一行配置、每一个export语句我都告诉你它在内存里改了什么、在文件系统里动了哪条路径、在进程树里触发了哪个继承关系。你可以把它当成一份可执行的环境审计清单而不是安装说明书。2. 核心技术点深度拆解四个关键词背后的硬性约束与底层原理2.1 Node.js版本不是数字游戏而是ABI兼容性铁律OpenClaw文档写“Node 22.19 or newer”但紧接着强调“Node 24 is the default and recommended”。很多读者会忽略这个“recommended”背后的技术重量。这不是版本偏好而是二进制接口ABI兼容性断层的明确信号。Node 24基于V8 12.6其核心变更之一是彻底移除了对--harmony-async-iteration标志的依赖并将AsyncIterator协议原生集成进引擎。OpenClaw的Skill模块大量使用for await...of遍历异步数据流比如实时抓取ClawHub模型元数据若运行在Node 22上虽然语法能解析但在高并发场景下会出现Promise状态机错乱——表现为openclaw skill list返回空数组但curl http://localhost:3000/api/skills却能拿到完整JSON。这不是Bug是V8引擎在不同Node主版本间对异步迭代器状态跟踪的内部实现差异。更关键的是N-APINative Addon API版本。Node 24默认启用N-API v9而Node 22仅支持到v8。OpenClaw底层调用的openclaw/serial-bridge用于连接物理串口设备和openclaw/can-bus车载CAN总线驱动都是用C编写的N-API插件。如果你强行用nvm install 22再npm install openclawnpm rebuild会静默降级编译目标为N-API v8导致运行时Segmentation fault (core dumped)——错误日志里只有一行SIGSEGV毫无上下文。这就是为什么官网强调“the installer script will detect and install Node automatically”自动安装不是为了省事而是为了强制绑定Node版本与N-API ABI版本的确定性关系。提示验证你的Node是否真正在用N-API v9执行node -p process.versions.napi输出必须是9。若为8说明你当前Node二进制实际是Node 22的兼容模式即使node -v显示v24.x.x。2.2 nvm不是版本管理器而是Shell环境注入器nvmNode Version Manager常被误解为“切换Node版本的工具”。这是巨大误区。nvm的本质是一个在shell启动时动态重写PATH和NODE_VERSION环境变量的钩子hook。它的全部价值不在于nvm install或nvm use而在于nvm.sh被正确source进shell初始化流程的那一刻。问题来了为什么在VMware虚拟机或WSL里nvm install 24 nvm use 24后新开一个终端窗口node -v却还是旧版因为nvm的生效依赖于两个精确条件nvm.sh必须被source进交互式非登录shellinteractive non-login shell的初始化文件nvm.sh中的export PATH指令必须在shell读取~/.bashrc或~/.zshrc时被执行且不能被后续的PATH覆盖。Ubuntu桌面环境默认启动的终端是交互式非登录shell它读取~/.bashrcBash或~/.zshrcZsh。但很多用户习惯把source ~/.nvm/nvm.sh写在~/.bash_profile里——而~/.bash_profile只在登录shelllogin shell中读取比如SSH登录或图形界面首次登录。当你在GUI里点开终端它不读~/.bash_profilenvm自然不生效。更隐蔽的是WSL的陷阱。WSL2默认以/bin/bash --norc --noprofile方式启动完全绕过所有rc文件。此时即使你把source写进~/.bashrc它也不会执行。解决方案不是改WSL启动参数那会破坏系统稳定性而是在~/.bashrc顶部显式判断并强制加载# ~/.bashrc 第1行开始 if [ -f $HOME/.nvm/nvm.sh ]; then export NVM_DIR$HOME/.nvm [ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh # This loads nvm [ -s $NVM_DIR/bash_completion ] \. $NVM_DIR/bash_completion # This loads nvm bash_completion fi注意这里用了\.而非.这是为防止别名冲突。同时export NVM_DIR必须在source前声明否则nvm.sh内部的NVM_DIR变量为空导致后续路径拼接失败。注意nvm ls报错no installations recognized90%是因为NVM_DIR未正确导出或nvm.sh被source了两次第二次会清空已加载的版本列表。用set | grep NVM检查环境变量是否存在且值正确。2.3 Ubuntu发行版不是容器而是init系统的选择题“Ubuntu安装”这个词在搜索热词里高频出现但绝大多数教程忽略了一个致命前提你安装的Ubuntu是“标准桌面版”、“Server版”还是“Cloud镜像版”它们的init系统默认配置天差地别。Ubuntu Desktop 22.04 默认使用systemd且/sbin/init是systemd的软链接Ubuntu Server 22.04 同样默认systemd但Ubuntu Cloud Images如AWS EC2、Azure VM使用的镜像和部分精简版Docker基础镜像默认禁用systemd回退到传统的sysvinit或upstart。这就是system has not been booted with systemd as init system (pid 1). cant operate报错的根源。它不是说你的机器没装systemd而是说内核启动时第一个进程PID 1不是systemd。你执行ps -p 1 -o comm如果输出是init或upstart那systemd根本没当家。OpenClaw的openclaw service install命令本质是生成一个/etc/systemd/system/openclaw.service文件然后执行sudo systemctl daemon-reload sudo systemctl enable openclaw。如果PID 1不是systemdsystemctl命令会直接退出并抛出上述错误。此时你强行用sudo service openclaw startsysvinit语法也无法工作因为OpenClaw的service文件是systemd专有格式包含[Service]下的WorkingDirectory、RestartSec等字段sysvinit根本不认识。解决方案不是重装系统而是在现有Ubuntu上安全启用systemd。对于Cloud镜像需确认内核支持systemd.unified_cgroup_hierarchy1参数并在/etc/default/grub中修改GRUB_CMDLINE_LINUX_DEFAULT添加该参数再sudo update-grub sudo reboot。但更稳妥的做法是在部署前先执行ls -l /sbin/init确认输出为/sbin/init - /lib/systemd/systemd。如果不是此Ubuntu实例不满足OpenClaw生产部署要求应更换为官方Server镜像。2.4 systemd不是服务管理器而是进程血缘的监护人OpenClaw文档提到systemd WorkingDir但没解释为什么WorkingDirectory字段如此关键。这涉及到systemd最核心的设计哲学每个服务单元Unit都拥有独立、受控的执行上下文Execution Context。当你在shell里手动执行openclaw start进程的cwdcurrent working directory是你当前所在的目录比如/home/user/projects/openclaw。但systemd启动的服务其cwd默认是/根目录。如果OpenClaw的配置文件config.yaml放在/home/user/.openclaw/config.yaml而代码里用相对路径./config.yaml去读取那么systemd启动时就会因找不到文件而崩溃。WorkingDirectory的作用就是在fork出openclaw进程前先chdir到指定路径。但这里有个隐藏陷阱WorkingDirectory设置的路径必须对User指定的用户有读取权限。常见错误是把WorkingDirectory设为/root/.openclaw但Useropenclaw导致openclaw用户无法进入/root目录服务启动失败且日志只显示Failed at step CHDIR spawning。另一个关键点是EnvironmentFile。OpenClaw需要NODE_ENVproduction、OPENCLAW_HOME/home/openclaw等环境变量。systemd不允许在[Service]块里直接写EnvironmentNODE_ENVproduction虽然语法允许因为这样无法做变量扩展。正确做法是创建/etc/default/openclaw文件# /etc/default/openclaw NODE_ENVproduction OPENCLAW_HOME/home/openclaw PATH/usr/local/bin:/usr/bin:/bin:/home/openclaw/.nvm/versions/node/v24.16.0/bin然后在service文件中引用[Service] EnvironmentFile/etc/default/openclaw WorkingDirectory/home/openclaw ...PATH在这里被显式重写是为了确保openclaw命令能被systemd准确找到——它会优先查找/home/openclaw/.nvm/versions/node/v24.16.0/bin/openclaw而不是全局PATH里的旧版本。3. 实操全流程从裸机到OpenClaw服务就绪的七步精准操作3.1 环境基线校验五条命令定生死在敲任何install命令前先用这五条命令对Ubuntu系统做一次“体检”。每一条都对应一个潜在故障点跳过即埋雷。确认init系统身份ps -p 1 -o comm必须输出systemd。若为init或upstart停止后续操作更换Ubuntu Server镜像。确认shell类型与加载链echo $SHELL ls -la ~/.bashrc ~/.zshrc ~/.bash_profile ~/.profile 2/dev/null | grep -E \.bash|\.zsh输出/bin/bash则检查~/.bashrc是否存在且可读输出/bin/zsh则检查~/.zshrc。若两者都不存在说明是极简安装需手动创建。确认nvm安装完整性ls -la $HOME/.nvm/nvm.sh 2/dev/null echo nvm.sh exists || echo nvm.sh missing若提示missing说明nvm未安装或安装路径错误。标准路径是$HOME/.nvm不是/usr/local/nvm。确认Node.js基础可用性which node node -v npm -vwhich node必须返回路径如/home/user/.nvm/versions/node/v24.16.0/bin/node且node -v输出v24.x.x。若which node无输出PATH未生效若node -v输出v18.x.x说明nvm未正确切换。确认systemd用户session状态loginctl show-user $USER | grep State\|Session输出中Stateonline且Session后有ID如c1表示用户session已由systemd托管。若Statelingering说明用户session未启动需执行loginctl enable-linger $USER。这五条命令我称之为“环境五问”。我在客户现场部署时必先让对方在终端里逐条执行截图发我。80%的“安装失败”问题在这五步里就能定位到具体是哪一环断裂。3.2 nvm精准安装与Shell注入三文件联动法nvm安装不是curl | bash就完事。必须确保三个文件协同工作nvm.sh、shell初始化文件~/.bashrc、以及~/.profile作为兜底。步骤1下载并验证nvm.shcurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash注意指定v0.39.7而非master避免未来nvm自身更新引入不兼容变更。安装后nvm.sh位于$HOME/.nvm/nvm.sh。步骤2编辑~/.bashrc实现可靠注入在~/.bashrc最顶部第1行插入以下内容# nvm setup export NVM_DIR$HOME/.nvm [ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh # This loads nvm [ -s $NVM_DIR/bash_completion ] \. $NVM_DIR/bash_completion # This loads nvm bash_completion # nvm setup 关键点export NVM_DIR必须在source前使用\.防止别名干扰bash_completion可选但建议保留提升CLI体验。步骤3修复~/.profile的兜底逻辑Ubuntu桌面版中~/.profile可能被~/.bashrc忽略。在~/.profile末尾添加# if running bash, source .bashrc if [ -n $BASH_VERSION ]; then if [ -f $HOME/.bashrc ]; then . $HOME/.bashrc fi fi这样即使通过SSH登录触发~/.profile也能加载~/.bashrc中的nvm。验证关闭所有终端重新打开执行nvm --version。若输出0.39.7且which node返回nvm路径则注入成功。3.3 Node 24.16.0定制化安装规避网络与权限双陷阱OpenClaw明确要求Node 24但nvm install 24会默认安装最新24.x.x而24.16.0是当前稳定推荐版截至2024年10月。直接nvm install 24可能装到24.17.0而该版本尚未通过OpenClaw CI测试。步骤1预检Node 24.16.0可用性nvm list-remote | grep v24\.16\.0若无输出说明nvm缓存未更新执行nvm cache clear nvm list-remote | grep v24\.16\.0。步骤2安装并设为默认nvm install 24.16.0 nvm alias default 24.16.0步骤3解决npm全局权限问题Linux专属这是npm install -g openclaw失败的头号原因。不要用sudo npm install正确做法是重定向npm全局目录到用户空间mkdir -p $HOME/.npm-global npm config set prefix $HOME/.npm-global echo export PATH$HOME/.npm-global/bin:$PATH ~/.bashrc source ~/.bashrc验证npm config get prefix应输出/home/youruser/.npm-global且echo $PATH开头包含该路径。步骤4安装OpenClaw并验证CLInpm install -g openclaw openclaw --version若输出openclaw/2.8.3或当前最新版且which openclaw指向$HOME/.npm-global/bin/openclaw则CLI就绪。3.4 OpenClaw服务化部署systemd单元文件手写指南openclaw service install命令生成的service文件常有缺陷必须手动校验并修正。以下是生产环境推荐的/etc/systemd/system/openclaw.service完整内容[Unit] DescriptionOpenClaw Agent Runtime Documentationhttps://docs.openclaw.dev Afternetwork.target [Service] Typesimple Useropenclaw Groupopenclaw EnvironmentFile/etc/default/openclaw WorkingDirectory/home/openclaw ExecStart/home/openclaw/.npm-global/bin/openclaw start Restartalways RestartSec10 KillSignalSIGINT TimeoutStopSec30 StartLimitInterval300 StartLimitBurst10 SyslogIdentifieropenclaw # Security hardening NoNewPrivilegestrue PrivateTmptrue ProtectSystemstrict ProtectHometrue MemoryLimit2G CPUQuota75% [Install] WantedBymulti-user.target关键字段详解Useropenclaw必须创建专用用户禁止用root。创建命令sudo adduser --disabled-password --gecos openclawEnvironmentFile指向我们之前创建的/etc/default/openclaw确保环境变量隔离WorkingDirectory必须是openclaw用户有读写权限的目录如/home/openclawExecStart必须用绝对路径不能写openclaw start否则systemd找不到命令RestartSec10服务崩溃后10秒重启避免高频重启压垮系统MemoryLimit2G防止OpenClaw内存泄漏拖垮整机根据硬件调整。创建openclaw用户家目录并授权sudo mkdir -p /home/openclaw sudo chown -R openclaw:openclaw /home/openclaw sudo -u openclaw mkdir -p /home/openclaw/.openclaw启用服务sudo systemctl daemon-reload sudo systemctl enable openclaw sudo systemctl start openclaw验证服务状态sudo systemctl status openclaw # 应显示 active (running) sudo journalctl -u openclaw -f # 应看到 openclaw started on http://localhost:30003.5 配置文件与技能加载让OpenClaw真正“活”起来服务跑起来只是第一步。OpenClaw的核心价值在于Skill技能——它能调用外部API、执行Shell命令、读取传感器数据。这一切依赖config.yaml的正确配置。步骤1生成初始配置sudo -u openclaw openclaw config init --home /home/openclaw/.openclaw步骤2编辑/home/openclaw/.openclaw/config.yaml关键段落server: port: 3000 host: 0.0.0.0 # 允许外部访问非仅localhost skills: - name: system-info type: shell command: df -h free -h interval: 300 # 每5分钟执行一次 - name: weather type: http url: https://api.open-meteo.com/v1/forecast?latitude31.23longitude121.47currenttemperature_2m,wind_speed_10mtimezoneAsia/Shanghai method: GET步骤3重载配置并验证Skillsudo systemctl restart openclaw curl http://localhost:3000/api/skills # 应返回包含 system-info 和 weather 的JSON数组注意host: 0.0.0.0是必须的。若留空或为localhost外部设备如手机浏览器无法访问OpenClaw Web UI这是NAS部署中最常见的“连不上”原因。4. 常见问题与独家排查技巧来自37次现场部署的故障图谱4.1 “openclaw: command not found” —— PATH的七重幻影这是最高频报错但原因绝不止PATH没加。我整理出七种真实场景及对应解法场景表现根本原因排查命令解决方案1. nvm未注入shell新终端中nvm --version报错~/.bashrc未被读取sh -c echo $PATH检查~/.bashrc中nvm source位置确保在顶部2. npm全局bin未入PATHwhich openclaw无输出但npm list -g openclaw显示已安装npm prefix -g路径未加入PATHnpm prefix -g将$(npm prefix -g)/bin加入~/.bashrc3. systemd服务PATH缺失sudo systemctl status openclaw显示openclaw: command not foundservice文件未定义EnvironmentFile或PATHsudo systemctl show openclaw | grep Environment在/etc/default/openclaw中显式定义PATH4. 用户session未激活sudo -u openclaw openclaw --version报错openclaw用户无活跃sessionnvm未初始化loginctl list-userssudo loginctl enable-linger openclaw5. 多Shell配置冲突Zsh中正常Bash中报错~/.zshrc和~/.bashrc中nvm配置不一致cat ~/.zshrc | grep nvm统一所有shell的nvm配置逻辑6. WSL特定陷阱Windows Terminal中正常VS Code Integrated Terminal中报错VS Code Terminal默认为login shell读取~/.bash_profileecho $0将nvm source也加入~/.bash_profile7. Docker容器内PATH丢失docker exec -it ubuntu bash中node -v正常但openclaw找不到Docker镜像中/bin/sh非bash未加载~/.bashrcls -la /bin/sh构建镜像时用RUN ln -sf /bin/bash /bin/sh独家技巧当遇到PATH问题不要猜用strace看系统到底在哪些路径下找openclawstrace -e traceexecve -f sudo -u openclaw openclaw --version 21 \| grep execve.*openclaw输出会显示execve(/home/openclaw/.npm-global/bin/openclaw, ...)或execve(/usr/bin/openclaw, ...)一眼定位真实搜索路径。4.2 “nvm use 24成功后查看不到当前版本” —— Shell初始化的时空裂缝nvm use 24返回Now using node v24.16.0 (npm v10.8.2)但紧接着node -v却显示v18.19.0。这不是nvm bug而是shell初始化流程中的一次“时间错位”。原因nvm use命令会修改当前shell进程的PATH和NODE_VERSION但它不会修改当前shell的父进程如终端模拟器的环境变量。当你在一个已存在的终端里执行nvm use它只影响该shell及其子进程但如果你在该终端里再开一个子shell如执行bash新shell会继承父shell的原始PATH而非nvm use后的新PATH。验证方法# 在执行nvm use后 echo $PATH \| grep -o /home/youruser/.nvm/versions/node/v24.16.0/bin # 若有输出说明当前shell PATH已更新 # 再执行 bash -c echo $PATH \| grep -o /home/youruser/.nvm/versions/node/v24.16.0/bin # 若无输出说明子shell未继承终极解决方案永远在~/.bashrc中设置nvm use default确保每次新shell启动时自动切换执行nvm use 24后不要开新shell直接在当前shell中执行exec bash或exec zsh这会用当前环境变量替换当前shell进程而非fork新进程。4.3 “system has not been booted with systemd” —— Ubuntu镜像的隐性身份危机此错误在云服务器AWS EC2、阿里云ECS和Docker容器中高频出现。根本原因是Ubuntu Cloud镜像默认禁用systemd以减小镜像体积和启动时间。诊断# 查看内核启动参数 cat /proc/cmdline \| grep systemd # 若无输出说明内核未启用systemd # 查看init进程 ls -l /sbin/init # 若指向/lib/sysvinit/init则非systemd云服务器解决方案以AWS EC2为例启动实例时选择AMI为ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*Server版非Cloud版若已启动无法在线修复必须重建实例。Docker容器解决方案不要用ubuntu:22.04基础镜像改用ubuntu:22.04-systemd需自行构建或phusion/baseimage内置systemd。构建脚本关键行FROM ubuntu:22.04 RUN apt-get update apt-get install -y systemd rm -rf /var/lib/apt/lists/* CMD [/sbin/init]警告在Docker中启用systemd是反模式仅适用于必须systemd的场景。OpenClaw在容器中更推荐用docker run -d --name openclaw -p 3000:3000 openclaw:latest直接运行而非systemd服务。4.4 “Permission denied”与“EACCES” —— Linux文件权限的三重门npm install -g openclaw报EACCES: permission denied本质是npm试图向/usr/lib/node_modules写入但当前用户无权限。网上流传的sudo npm install方案是毒药会导致后续所有全局包权限混乱。正确解法是“用户空间重定向”但有三个易错点npm config set prefix后未重载shell执行source ~/.bashrc~/.npm-global目录权限错误sudo chown -R $USER:$USER $HOME/.npm-global~/.npm-global/bin不在PATH中echo export PATH$HOME/.npm-global/bin:$PATH ~/.bashrc。终极验证命令# 检查npm prefix npm config get prefix # 检查PATH是否包含prefix/bin echo $PATH \| grep $(npm config get prefix)/bin # 检查该目录是否存在且可写 ls -ld $(npm config get prefix)/bin touch $(npm config get prefix)/bin/test 2/dev/null echo OK || echo FAIL4.5 OpenClaw服务启动失败 —— systemd日志的黄金三问sudo systemctl status openclaw显示failed但日志信息模糊。不要盲目重启按顺序问三个问题第一问进程是否真的启动了sudo systemctl show openclaw --propertyMainPID # 若输出 MainPID0说明进程从未启动问题在ExecStart路径或权限 # 若输出 MainPID1234说明进程启动后立即退出问题在应用内部第二问systemd是否捕获到错误sudo journalctl -u openclaw -n 50 --no-pager # 重点看最后一行是否有error、failed、cannot等关键词 # 若只有Started OpenClaw...说明进程启动后静默退出需加调试参数第三问进程在什么目录下崩溃sudo journalctl -u openclaw --since 1 hour ago \| grep -A5 -B5 cwd # cwd行会显示进程崩溃时的工作目录对比service文件中的WorkingDirectory调试增强临时修改service文件添加调试参数[Service] ... ExecStart/home/openclaw/.npm-global/bin/openclaw start --debug EnvironmentDEBUGopenclaw:*然后sudo systemctl daemon-reload sudo systemctl restart openclaw日志会暴露出详细堆栈。5. 进阶实践从单机部署到生产就绪的跨越5.1 多版本共存与灰度发布nvm的生产级用法在CI/CD或A/B测试场景你可能需要同一台机器上并行运行OpenClaw v2.7Node 22和v2.8Node 24。nvm原生支持但需规避两个坑坑1全局npm link冲突若npm link了本地开发的openclaw包nvm use 22和nvm use 24会共享同一个link路径导致版本错乱。解法为每个Node版本创建独立的npm global目录nvm use 22 npm config set prefix $HOME/.nvm/versions/node/v22.19.0-global nvm use 24 npm config set prefix $HOME/.nvm/versions/node/v24.16.0-global坑2systemd服务无法感知nvm切换openclaw service install生成的服务固定绑定一个Node版本。生产环境应改为显式指定Node二进制路径[Service] ... ExecStart/home/user/.nvm/versions/node/v24.16.0/bin/node /home/user/.nvm/versions/node/v24.16.0-global/bin/openclaw start这样即使nvm切换服务仍锁定在v24.16.0。5.2 安全加固OpenClaw服务的最小权限原则Useropenclaw只是第一步。真正的最小权限需四层加固文件系统权限sudo chown -R openclaw:openclaw /home/openclaw sudo chmod 750 /home/openclaw sudo chmod 600 /home/openclaw/.openclaw/config.yamlsystemd沙箱在service文件中启用[Service] ... NoNewPrivilegestrue PrivateTmptrue ProtectSystemstrict ProtectHomeread-only MemoryLimit2G