修改 /etc/profile 后仅对新登录用户生效，老会话需手动 source /etc/profile 临时更新，systemd 服务和 cron 任务则完全不加载该文件，须显式配置环境变量。
修改 /etc/profile 后只对新登录用户生效，老会话不更新
这是最常被忽略的点：/etc/profile 是在用户登录时执行的，不是每次打开终端就重载。所以即使你 source /etc/profile，也只影响当前 shell 进程及其子进程，不会“广播”给已存在的其他终端或服务进程。
常见错误现象：改完 PATH 后，新开一个终端能用新命令，但旧终端里 which xxx 找不到，systemctl start xxx 仍报 “command not found”。
- 对交互式终端：必须新开一个 login shell（比如退出再 ssh 登录，或运行
exec bash -l）才能完整重走登录流程 - 对 systemd 服务：它们根本不读
/etc/profile，而是依赖Environment=或EnvironmentFile=显式声明，或从父进程继承（而父进程往往没 reload 过 profile） - 对 cron job：默认使用
/bin/sh，且不加载任何 profile，需在 crontab 中显式. /etc/profile; your_command或改用bash -l -c 'your_command'
/etc/profile.d/ 脚本为何有时不生效
系统级环境变量推荐放 /etc/profile.d/*.sh，但生效前提是该目录被 /etc/profile 正确包含——CentOS 7 默认有这行：for i in /etc/profile.d/*.sh; do ...。如果某人手动删过或注释掉它，脚本就完全不执行。
容易踩的坑：
- 文件名必须以
.sh结尾，/etc/profile.d/myenv不会被加载，必须是/etc/profile.d/myenv.sh - 脚本内不能用
#!/bin/bash开头（会被当作独立脚本执行，而非 source），应直接写export VAR=value - 权限必须是可读（
644即可），不可执行（chmod 644 /etc/profile.d/myenv.sh） - 若脚本中用了
$(command)或依赖其他变量，要确认执行顺序——/etc/profile.d/下文件按字母序加载，java.sh早于python.sh，但晚于00-common.sh
systemd 服务看不到你设的 PATH 怎么办
systemd 服务启动时，环境变量几乎清空，只保留极简白名单（如 LANG、HOME）。你改的 /etc/profile 对它完全无效。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
正确做法是直接在 unit 文件里声明：
- 编辑服务文件：
sudo systemctl edit --full your-service.service - 在
[Service]段下加：Environment="PATH=/usr/local/bin:/usr/bin:/bin:/opt/java/bin"（注意：这里必须写全路径，不能用$PATH） - 或者用
EnvironmentFile=/etc/sysconfig/your-service外挂配置文件 - 改完后必须
sudo systemctl daemon-reload，再sudo systemctl restart your-service
别试图在 /etc/environment 里写 PATH——systemd 会读它，但只认 KEY=VALUE 格式，不支持 $PATH 展开，且无法追加，只能覆盖。
为什么 source /etc/profile 有时报错或部分失效
/etc/profile 本身会 source /etc/profile.d/*.sh，但如果某个 .sh 脚本语法错误（比如漏了 export、用了 Bash 特性但被 dash 解析），整个 source 就中断，后续变量不会加载。
排查建议：
- 逐个测试：
for f in /etc/profile.d/*.sh; do echo "$f"; bash -n "$f"; done检查语法 - 临时屏蔽可疑脚本：
mv /etc/profile.d/broken.sh /etc/profile.d/broken.sh.off，再source /etc/profile - 注意变量覆盖顺序：后加载的脚本会覆盖先加载的同名变量，比如
java.sh设了JAVA_HOME，但custom.sh又设了一次，后者生效
真正麻烦的是那些“看似生效、实则被覆盖”的情况——比如你改了 /etc/profile 里的 PATH，但某个 /etc/profile.d/ 脚本又把它重置了，这种链式覆盖很难一眼发现。
