宝塔Supervisor插件安装失败主因是Python环境异常或pip源不可达，需用宝塔Python重装pip并指定版本安装；运行报ImportError需确认模块装入正确路径；WSL需补全systemd模拟层；守护进程启动失败应检查.ini中command绝对路径及权限。
Supervisor插件安装卡在“正在安装”或报pip install supervisor失败
宝塔面板安装Supervisor插件时卡住或直接报错，大概率不是界面问题，而是底层pip命令执行失败。根本原因常出在Python环境不可用或pip源不可达——尤其在非标准系统（如某些精简版CentOS、WSL、或被手动改过pip源的服务器）上更明显。
先确认Python路径是否真实可用：/www/server/python/bin/python3 是宝塔默认Python 3路径，但部分旧面板可能指向/usr/bin/python3，而后者可能缺失pip或版本太低。
- 执行
/www/server/python/bin/python3 -m pip --version，若报ModuleNotFoundError: No module named 'pip'，说明pip未安装或损坏 - 执行
curl -I https://pypi.org/simple/supervisor/，检查是否能连通PyPI主源；超时或返回403，说明网络受限或pip源被污染 - 查看当前pip源：
/www/server/python/bin/python3 -m pip config list，若输出含global.index-url='https://mirrors.aliyun.com/pypi/simple/'等国内镜像，但该镜像临时不可用，也会导致安装中断
修复方式优先走最小改动：用宝塔自带Python重装pip再试安装：
/www/server/python/bin/python3 -m ensurepip --upgrade /www/server/python/bin/python3 -m pip install --upgrade pip /www/server/python/bin/python3 -m pip install supervisor==4.2.5
完成后，回到宝塔面板「软件商店」→「Supervisor进程管理器」→「卸载」→「重新安装」。不要跳过卸载步骤，否则旧缓存配置可能干扰新安装。
立即学习“Python免费学习笔记（深入）”；
安装后点“启动服务”无反应，日志显示ImportError: No module named supervisor
这说明Supervisor插件虽安装成功，但运行时找不到supervisor模块。不是没装，而是Python解释器没加载对——宝塔面板内部调用的是/www/server/python/bin/python3，但它可能没把site-packages路径加入sys.path，或者模块装到了另一个Python环境里。
验证方式很简单：在终端执行
/www/server/python/bin/python3 -c "import supervisor; print(supervisor.__file__)"
如果报错，就说明模块确实不在这个Python下。常见原因和对应操作：
- 你之前用
python3 -m pip install supervisor装到了系统Python（如/usr/bin/python3），而宝塔只认自己的/www/server/python/目录 → 必须用/www/server/python/bin/python3 -m pip install重装 - 宝塔Python是静态编译版，不带
ssl模块，导致pip无法验证HTTPS证书 → 执行/www/server/python/bin/python3 -m pip install --trusted-host pypi.org --trusted-host files.pythonhosted.org supervisor - 模块装进去了，但权限不对（比如root装、面板进程以www用户跑）→ 检查
/www/server/python/lib/python3.x/site-packages/supervisor*是否www用户可读，必要时chown -R www:www /www/server/python/lib/python3.x/site-packages/supervisor*
WSL环境下安装Supervisor插件后始终提示systemctl: command not found
这不是Supervisor的问题，是WSL本身没systemd。宝塔Supervisor插件依赖systemctl start supervisord来拉起服务，而WSL默认用init进程，systemctl根本不存在。
不能靠“重启WSL”或“换发行版”解决，必须补全systemd模拟层：
- 先确认是否已装
docker-systemctl-replacement：执行which systemctl，若返回/bin/systemctl且内容是Python脚本，说明已部署；否则需手动安装 - 安装命令必须用宝塔Python路径：因为WSL中
/usr/bin/python3可能没pip，而宝塔Python有完整工具链 →wget https://raw.githubusercontent.com/gdraheim/docker-systemctl-replacement/master/files/docker/systemctl.py -O /bin/systemctl && chmod +x /bin/systemctl - 别漏掉依赖：该脚本依赖
python3-distutils，在Ubuntu系需apt install python3-distutils -y，否则systemctl start supervisord会报ImportError: No module named distutils.util
装完后立刻测试：systemctl --version 应输出含 docker-systemctl-replacement 字样；再执行 systemctl start supervisord && systemctl status supervisord，看到 active (running) 才算真正打通。
安装成功但添加守护进程后状态一直是“已停止”，点启动没反应
表面是Supervisor没干活，实际90%是启动命令写错了，且错误被静默吞掉。Supervisor不会把子进程stderr打到面板日志里，得去子配置文件里翻原始错误。
所有守护进程的配置都落在：/www/server/panel/plugin/supervisor/profile/ 下的.ini文件。打开对应文件，重点看这几项：
-
command=：必须是**绝对路径+完整参数**，不能用~或$PATH变量；例如写php artisan queue:work会失败，要写成/www/server/php/81/bin/php /www/wwwroot/app/artisan queue:work -
directory=：必须存在且进程用户有执行权限；常见坑是填了/www/wwwroot/app但实际路径是/www/wwwroot/app/（末尾斜杠差异导致cd失败） -
user=：若填www但该用户被禁用了shell（/sbin/nologin），会导致进程无法启动；可临时改成root测试，确认后再按最小权限原则回调 -
autostart=false：插件UI里没勾“开机自启”时，该项为false，需手动点启动；但若命令本身有语法错误，点启动也不会生效，只会快速变回“已停止”
最有效的排错动作：切换到directory路径，用user身份手动执行一遍command，看终端是否报错。比如sudo -u www /www/server/php/81/bin/php /www/wwwroot/app/artisan queue:work —— 这一步省掉，后面所有排查都是蒙的。
