一、问题背景：Shell任务跑着跑着就“抽风”了
做过定时任务调度的朋友，大概率都碰到过这么个闹心事儿：本地测好的Shell脚本，放到调度平台上跑，有时候正常，有时候却报错，而且报错的原因特别奇怪——要么是系统命令找不到，要么是环境变量没生效，甚至连脚本里写的软链接都找不到。我之前用DolphinScheduler（以下简称DS）调度Shell任务时，就踩过这个坑：有个用来同步数据的Shell脚本，本地跑一次成一次，放到DS上，隔三差五就报“mysql: command not found”，但有时候又能正常跑，完全没规律。折腾了快一周，才搞明白这是执行环境不一致的问题——DS给每个Shell任务分配的运行环境，和你本地登录服务器的环境，根本不是一回事儿。
二、核心原因：为啥DS的执行环境会变？
要解决这个问题，得先搞懂DS跑Shell任务的底层逻辑，还有环境变量到底是怎么加载的。
2.1 DS运行Shell任务的底层流程
DS调度任务时，不会直接用你登录服务器的账号环境，而是走一套独立的流程：
- 任务触发后，DS的Worker节点会启动一个新的进程，用来执行这个Shell任务；
- 这个进程会先加载DS配置里指定的用户环境（默认是DS本身运行的用户，比如dolphinscheduler）；
- 然后再加载Shell脚本开头指定的解释器（比如#!/bin/bash）对应的环境；
- 最后才执行脚本里的命令。
这里最容易出问题的是第二步：如果DS配置的用户环境没配好，或者脚本里没指定要加载的环境变量，就会导致环境不一致。
2.2 环境变量加载的“坑”
Shell的环境变量加载是有顺序的，不同场景下加载的文件完全不一样：
- 本地登录服务器时（交互式Shell），会依次加载/etc/profile、~/.bash_profile、~/.bashrc等文件；
- DS跑Shell任务时（非交互式Shell），默认只会加载/etc/profile和~/.bashrc，很多时候不会加载~/.bash_profile；
- 如果DS的Worker节点用的是系统默认的Shell解释器（比如/bin/sh，而不是/bin/bash），加载的文件还会更少。
举个例子：你把mysql的环境变量写在了~/.bash_profile里，本地登录时能加载到，所以mysql命令能用；但DS跑任务时没加载~/.bash_profile，所以就会报“command not found”。
三、完整示例：重现并解决环境不一致问题
为了让大家更清楚，我做了一套完整的示例，技术栈统一用Shell + DolphinScheduler 3.2.0（当前主流稳定版）。
3.1 准备测试脚本
先写一个用来测试环境的Shell脚本，用来输出当前的环境变量、用户、解释器等信息，方便对比本地和DS上的环境差异。
#!/bin/bash
# 测试脚本：test_env.sh
# 功能：输出当前执行环境的关键信息
# 1. 输出当前运行的Shell解释器
echo "当前Shell解释器：$SHELL"
# 2. 输出当前登录的用户
echo "当前运行用户：$(whoami)"
# 3. 输出PATH环境变量（关键，用来判断命令是否能找到）
echo "当前PATH环境变量：$PATH"
# 4. 测试mysql命令是否存在
if command -v mysql &> /dev/null; then
echo "mysql命令存在，版本为：$(mysql --version)"
else
echo "mysql命令不存在！"
fi
# 5. 输出当前工作目录
echo "当前工作目录：$(pwd)"
把这个脚本放到DS的Worker节点的/data/ds/scripts/目录下，然后给它加执行权限：
# 给脚本加执行权限
chmod +x /data/ds/scripts/test_env.sh
3.2 本地测试环境
先在本地登录Worker节点（用root用户，或者你自己的测试用户），运行这个脚本，看输出是什么样的：
# 本地运行测试脚本
/data/ds/scripts/test_env.sh
假设本地的输出是这样的：
当前Shell解释器：/bin/bash
当前运行用户：root
当前PATH环境变量：/usr/local/mysql/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
mysql命令存在，版本为：mysql Ver 8.0.34 for Linux on x86_64 (MySQL Community Server - GPL)
当前工作目录：/root
这里能看到，PATH里包含了/usr/local/mysql/bin，所以mysql命令能找到。
3.3 DS上运行的异常情况
接下来在DS上创建一个Shell任务，任务的执行命令就是/data/ds/scripts/test_env.sh，然后运行这个任务，看DS的日志输出是什么样的。假设DS的输出是这样的：
当前Shell解释器：/bin/bash
当前运行用户：dolphinscheduler
当前PATH环境变量：/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
mysql命令不存在！
当前工作目录：/home/dolphinscheduler
对比本地和DS的输出，差异非常明显：
- 运行用户不一样：本地是root，DS是dolphinscheduler；
- PATH环境变量不一样：DS的PATH里没有/usr/local/mysql/bin，所以mysql命令找不到；
- 工作目录不一样：本地是/root，DS是/home/dolphinscheduler。
这就是典型的环境不一致问题。
3.4 解决方法一：脚本内显式加载环境变量
最直接的解决方法，是在脚本的开头，显式加载你需要的环境变量文件，比如你本地的~/.bash_profile，或者专门写一个环境变量配置文件。
修改测试脚本，在开头加上加载环境变量的命令：
#!/bin/bash
# 测试脚本：test_env.sh
# 功能：输出当前执行环境的关键信息
# 解决方法一：显式加载环境变量文件
# 加载root用户的环境变量（如果脚本需要用root的环境）
source /root/.bash_profile
# 或者加载专门的环境配置文件（比如/data/ds/env/mysql.env）
# source /data/ds/env/mysql.env
# 1. 输出当前运行的Shell解释器
echo "当前Shell解释器：$SHELL"
# 2. 输出当前登录的用户
echo "当前运行用户：$(whoami)"
# 3. 输出PATH环境变量（关键，用来判断命令是否能找到）
echo "当前PATH环境变量：$PATH"
# 4. 测试mysql命令是否存在
if command -v mysql &> /dev/null; then
echo "mysql命令存在，版本为：$(mysql --version)"
else
echo "mysql命令不存在！"
fi
# 5. 输出当前工作目录
echo "当前工作目录：$(pwd)"
这样修改后，再在DS上运行任务，就会加载/root/.bash_profile里的环境变量，PATH里就会有/usr/local/mysql/bin，mysql命令就能找到了。
3.5 解决方法二：修改DS的Worker配置
如果很多脚本都需要用到同一个环境变量，每次都在脚本里加source命令太麻烦，可以直接修改DS的Worker配置，让所有Shell任务都加载指定的环境变量。
修改DS的Worker配置文件（conf/worker.properties），找到worker.env-path这个配置项，把它改成你需要加载的环境变量文件路径：
# 解决方法二：修改Worker的环境变量配置
# 把默认的空值改成你要加载的环境变量文件路径
worker.env-path=/root/.bash_profile
修改后，重启Worker节点，之后所有的Shell任务都会自动加载这个配置文件里的环境变量，不用再改每个脚本了。
3.6 解决方法三：指定DS任务的运行用户
如果你的脚本需要用root用户的环境，还可以在DS创建Shell任务时，指定任务的运行用户为root，而不是默认的dolphinscheduler用户。
创建任务时，在“执行用户”下拉框里选择root（如果没有的话，需要先在DS的“安全中心-用户管理”里添加root用户），然后运行任务，任务就会用root用户的环境来执行，和本地的环境就一致了。
四、应用场景、优缺点与注意事项
4.1 应用场景
环境不一致的问题，几乎会出现在所有用DS调度Shell任务的场景，尤其是以下几种：
- 依赖第三方命令的任务：比如用mysql、redis-cli、docker等系统命令的任务；
- 依赖自定义环境变量的任务：比如自己定义的JAVA_HOME、MAVEN_HOME等；
- 依赖特定用户权限的任务：比如需要root权限才能执行的系统操作；
- 依赖软链接或工作目录的任务：比如脚本里用了相对路径的软链接，或者依赖当前工作目录的文件。
4.2 三种解决方法的优缺点对比
| 解决方法 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 脚本内显式加载 | 灵活，只影响当前脚本，不会影响其他任务；不用改DS配置，不用重启服务 | 每个脚本都要加source命令，重复工作量大 | 单个特殊脚本，或者不同脚本需要不同环境的场景 |
| 修改Worker配置 | 一次配置，所有Shell任务生效，不用改每个脚本 | 会影响所有Worker节点上的Shell任务，可能会带来冲突；修改后需要重启Worker | 所有任务都需要同一个环境的场景 |
| 指定运行用户 | 环境和本地完全一致，不用改脚本也不用改配置 | 需要给DS配置root用户，有一定的安全风险；如果任务需要用普通用户的环境，不适用 | 任务需要特定用户权限，且该用户环境和本地一致的场景 |
4.3 注意事项
- 加载环境变量时，要注意文件的权限：比如你要加载/root/.bash_profile，那DS的运行用户（比如dolphinscheduler）必须有读取这个文件的权限，否则source命令会失败；
- 不要随便用root用户运行所有任务：root用户权限太高，如果任务有漏洞，会带来安全风险；
- 测试时要对比环境：每次修改后，都要在本地和DS上分别运行测试脚本，对比环境变量、用户、工作目录等信息，确保一致；
- 避免依赖交互式Shell的环境：尽量把脚本需要的环境变量都显式写出来，不要依赖本地登录时的默认环境；
- 软链接的问题：如果脚本里用到了软链接，要确保DS的工作目录和本地的工作目录一致，或者用绝对路径指定软链接的位置。
五、文章总结
DS中Shell任务执行环境不一致的问题，本质上是本地交互式Shell和DS非交互式Shell的环境加载逻辑不同导致的。解决这个问题的核心思路，就是让DS的执行环境和本地的环境尽可能一致。
实际使用时，建议根据自己的场景选择合适的解决方法：如果是单个特殊脚本，就用脚本内显式加载的方法；如果是所有任务都需要同一个环境，就修改Worker配置；如果任务需要特定用户的环境，就指定运行用户。同时，一定要注意权限和安全问题，避免因为环境配置不当带来的风险。
最后，给大家提个小建议：写Shell脚本时，尽量用绝对路径，显式加载需要的环境变量，不要依赖默认的环境，这样能大大减少环境不一致的问题。
评论
围绕“DolphinScheduler中Shell任务执行环境不一致的问题解决”参与讨论