WAS启动startManager报错，是什么原因，如何排查解决？

在WebSphere Application Server (WAS) 的运维管理中，启动部署管理器是构建和管理一个单元环境的首要步骤，执行 startManager.sh（或 startManager.bat）命令时遇到报错，是许多系统管理员都可能面临的棘手问题，这类错误往往由多种因素导致，从基础环境配置到复杂的网络或文件系统问题都有可能，本文旨在提供一个系统化、结构清晰的排查思路，帮助您定位并解决 startManager 启动失败的问题。

错误诊断的起点：解读日志信息

当 startManager 命令失败时，最直接、最有效的信息来源是日志文件，切忌仅凭控制台输出的寥寥数语进行判断，WAS 在启动过程中会生成详细的日志，记录了每一个步骤的执行情况和失败原因。

关键日志文件位置：
<WAS_Profile_Root>/logs/startManager.log

这个日志文件是启动管理器过程的专属日志,包含了从环境变量检查、JVM 启动到服务器初始化的全过程，错误信息的末尾会包含一个关键的错误代码，ADMU0111E、ADMU0027E 等，这些代码是定位问题的金钥匙。

• ADMU0111E: 程序检查失败：这通常意味着启动前的某个基础检查未通过，比如指定的端口已被占用、Java 环境配置错误或必要的文件权限不足。
• ADMU0027E: 启动失败，异常信息…：这个错误更为通用，其后通常会跟随具体的异常堆栈，如 IOException、ClassNotFoundException 或与 SSL 相关的异常，需要仔细分析。

除了 startManager.log，还应检查 <WAS_Profile_Root>/logs/server1/SystemOut.log 和 SystemErr.log，它们包含了 JVM 启动后的应用和系统级输出，能提供更深层次的线索。

基础环境与配置核查

在深入分析复杂的日志之前,首先应回归基础，确保运行环境是健康和正确的，许多看似复杂的问题，根源往往在于基础配置的疏忽。

• 环境变量：确认 WAS_HOME 和 JAVA_HOME 环境变量是否已正确设置，并且指向了正确的 WAS 安装目录和 JDK 版本，可以通过 echo $WAS_HOME 和 echo $JAVA_HOME 命令验证，检查 PATH 变量是否包含了 $JAVA_HOME/bin 和 $WAS_HOME/bin。
• 用户权限：执行启动命令的用户必须对整个 WAS 安装目录（特别是 Profile 目录）拥有完整的读写和执行权限，可以使用 ls -l 命令检查目录权限，必要时使用 chown 和 chomd 进行修正。
• Java 环境：确保 WAS 所使用的 JDK 版本是受支持的，并且没有损坏，可以尝试运行 $JAVA_HOME/bin/java -version 来验证 Java 本身是否能正常工作。
• 磁盘空间：检查 Profile 所在的文件分区是否有足够的剩余空间，空间不足会导致日志文件无法写入或临时文件创建失败，从而引起启动中断。

网络与端口问题排查

网络配置是导致 startManager 失败的另一大常见原因，尤其是在分布式环境中，管理器需要通过特定的端口与节点代理进行通信。

• 端口冲突：管理器默认使用 SOAP 连接器端口（默认为 8879）进行管理通信，如果该端口已被其他进程占用，管理器将无法启动，在 Linux/Unix 系统上，可以使用 netstat -anp | grep 8879 或 lsof -i :8879 来查看端口占用情况，在 Windows 上，则可以使用 netstat -ano | findstr 8879。
• 主机名解析：WAS 严重依赖主机名进行节点间的识别和通信，必须确保服务器的主机名能够被正确解析到其 IP 地址，检查 /etc/hosts（Linux/Unix）或 C:WindowsSystem32driversetchosts（Windows）文件，确保其中包含正确的映射关系，0.0.1 localhost 和服务器的实际 IP 与主机名映射，错误的 hosts 文件配置是导致“连接被拒绝”等问题的常见元凶。
• 防火墙设置：检查本地服务器和任何网络硬件防火墙的规则，确保管理器所使用的端口（包括 SOAP 端口、WC_adminhost 等）没有被阻止。

配置文件与同步状态检查

如果基础环境和网络均无问题,那么问题可能出在 WAS 的配置文件本身。

• 配置文件损坏：WAS 的配置文件（位于 <WAS_Profile_Root>/config 目录下）是 XML 格式的，如果因为非正常关机、手动误改或磁盘错误导致文件损坏，启动过程就会失败，虽然手动编辑这些文件风险很高，但可以检查其是否为完整的 XML 格式。
• 节点同步问题：如果管理器之前是正常运行的，但最近做过配置更改后无法启动，可能是节点同步出现了问题，虽然这是在管理器启动后影响节点的问题，但在某些极端情况下，不一致的配置状态也可能反过来影响管理器。

常见错误场景与解决方案速查表

为了更直观地应对问题,下表汇总了一些常见的错误场景及其对应的排查方向和解决方案。

错误现象或日志关键词	可能原因	推荐解决方案
ADMU0111E 或 Address already in use	端口被占用	使用 netstat 或 lsof 找到占用端口的进程并终止，或修改管理器的 SOAP 端口配置。
Connection refused	防火墙阻止、服务未运行、主机名解析错误	检查防火墙规则；使用 ps -ef | grep java 确认无残留进程；验证 /etc/hosts 文件。
IOException 或文件相关错误	磁盘空间不足、文件权限错误、配置文件损坏	使用 df -h 检查磁盘空间；使用 ls -l 检查并修正权限；考虑从备份恢复配置。
SSL/TLS 相关异常（如 SSLHandshakeException）	密钥库或信任库配置错误、证书过期或无效	通过管理控制台或 wsadmin 脚本检查和重新配置 SSL 证书。
OutOfMemoryError	JVM 内存设置过小	编辑 <WAS_Profile_Root>/config/cells/<cell_name>/nodes/<node_name>/servers/server1/server.xml，增大 JVM 堆大小。

---

相关问答FAQs

问题1：如何确认部署管理器（DMGR）是否已经成功启动？

解答： 确认 DMGR 成功启动可以通过以下三种方式：

1. 检查日志：查看 <WAS_Profile_Root>/logs/startManager.log，文件末尾应出现 “Server server1 open for e-business” 或类似的成功启动信息，且没有 ADMU0111E 等错误代码。
2. 检查进程：在操作系统中使用 ps -ef | grep java (Linux/Unix) 或任务管理器 (Windows) 查看是否存在名为 WebSphere_Portal 或类似包含 DMGR 进程 ID 的 Java 进程。
3. 访问管理控制台：尝试在浏览器中访问管理控制台，默认地址是 http://<DMGR_Hostname>:9060/ibm/console，如果能够正常登录，则证明 DMGR 已成功启动并运行。

问题2：启动管理器时提示端口被占用（Address already in use），但该端口并没有其他应用在使用，该怎么办？

解答： 这种情况通常是由于上一次管理器进程未能正常关闭，导致一个“僵尸”Java 进程依然绑定着该端口。

1. 定位僵尸进程：执行 netstat -anp | grep <端口号> (Linux) 或 netstat -ano | findstr <端口号> (Windows)，找到占用端口的进程 ID (PID)。
2. 确认进程：使用 ps -ef | grep <PID> (Linux) 或任务管理器按 PID 查找 (Windows)，确认该进程确实是 WAS 的残留进程。
3. 强制终止：使用 kill -9 <PID> (Linux) 或 taskkill /F /PID <PID> (Windows) 命令强制终止该进程。
4. 重新启动：清理完毕后，再次执行 startManager 命令即可，如果问题依旧存在，可以考虑重启操作系统，以确保所有网络资源被完全释放。