Linux下启动WAS有哪些常用命令
在Linux服务器上启动WebSphere Application Server，最核心的命令就是startServer.sh。这个脚本位于WAS安装目录的profiles/你的配置文件名/bin下。比如你创建了一个名为AppSrv01的配置文件，完整路径就是/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/startServer.sh server1。这里的server1是默认的应用服务器名称，如果你有多个服务器，替换成对应的名字就行。
使用前需要确保你有执行权限，通常用chmod +x startServer.sh赋予可执行权限。执行时如果遇到权限不够，就用su - wasadmin切换到was安装用户再操作。很多新手忘了切换用户linux 启动 was 命令，直接用root执行，结果启动后文件权限全乱套，后面维护起来很头疼。
还有一种情况是你需要后台启动，不让启动日志刷满屏幕。这时候加上&符号放到后台运行，比如./startServer.sh server1 &。如果你想知道启动日志，可以重定向到文件：./startServer.sh server1 > /tmp/start.log 2>&1 &，这样错误信息也一并记录。
启动前需要检查哪些环境变量
启动WAS前，环境变量没配好linux 启动 was 命令，命令跑起来直接报错。最常见的变量是JAVA_HOME和WAS_HOME。JAVA_HOME指向你安装的Java路径，比如/opt/IBM/WebSphere/AppServer/java；WAS_HOME指向WAS安装根目录，比如/opt/IBM/WebSphere/AppServer。
你可以用echo $JAVA_HOME和echo $WAS_HOME检查当前值。如果发现为空或者指向了错误的路径，就到~/.bash_profile或/etc/profile里加上这两行：
export JAVA_HOME=/opt/IBM/WebSphere/AppServer/java
export WAS_HOME=/opt/IBM/WebSphere/AppServer
改完记得执行source ~/.bash_profile让配置生效。
另外，有时候你可能会遇到./startServer.sh: line 1: ./java/bin/java: No such file or directory这种错误，实际上Java文件就在那里linux系统iso下载redflag linux，但系统找不到。检查一下<WAS_HOME>/bin/setupCmdLine.sh这个脚本，它负责设置路径，确保它存在并且可执行。如果这个脚本损坏了，启动命令会直接中断。
启动时遇到报错怎么快速定位
启动WAS时，常见报错之一是”ADMU3000E: Server server1 is not open for business”。这通常意味着端口被占用或者配置文件有问题。先用netstat -anp | grep 端口号查一下，WAS默认的9080和9043端口是否被其他进程占了。如果端口被占用，杀掉那个进程，或者修改WAS的端口配置。
还有一种报错是”Failed to initialize the WSAdmin object”，这往往是因为Node Agent没启动或者同步失败。先启动Node Agent：./startNode.sh，等它完全运行后再去启动应用服务器。你要是看到”Could not find the class file for com.ibm.ws.runtime.WsServer”，那多半是WAS安装不完整或者某些jar包被误删了，只能重装或者从备份恢复。
日志文件是定位问题的最佳帮手。启动日志在<WAS_HOME>/profiles/AppSrv01/logs/server1/SystemOut.log里，用tail -f实时查看最新输出。如果遇到内存溢出或配置错误，日志里会有明确的Java异常堆栈。不要只看最后几行，有时错误在启动过程中期就发生了，滚动日志翻一下。
如何让WAS随Linux系统自启动
生产环境里，每次重启Linux都要手动启动WAS太麻烦了。你可以把启动命令写入/etc/rc.local实现自启动。编辑这个文件，加上一行：su - wasadmin -c "/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/startServer.sh server1"。注意用su -切换到wasadmin用户，避免权限问题。
如果你用的是systemd的Linux发行版，比如CentOS 7或RHEL 7以上，写一个systemd服务更规范。在/etc/systemd/system/下创建was.service文件，内容大致这样：
[Unit]
Description=WebSphere Application Server
After=network.target
[Service]
Type=forking
User=wasadmin
ExecStart=/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/startServer.sh server1
ExecStop=/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/stopServer.sh server1
Restart=on-failure
[Install]
WantedBy=multi-user.target
然后执行systemctl daemon-reload和systemctl enable was，以后每次开机自动就跑起来了。
要注意的是，如果WAS有多个节点或集群，自启动脚本里要依次启动Node Agent和各个应用服务器。顺序很重要：先启动Node Agent，再启动应用服务器；停止时反过来。否则集群节点之间可能无法正常通信。
停止和重启WAS的常用命令
停止WAS用stopServer.sh，同样在bin目录下。命令是./stopServer.sh server1。如果你需要强制停止，加-stopnow参数，比如./stopServer.sh server1 -stopnow。这个参数会立即终止Java进程，但可能造成未提交的事务丢失，所以尽量在非高峰时段使用。
重启WAS没有一条命令直接搞定，通常要手动执行停止再启动。你可以写一个简单的脚本，比如叫restart.sh，放在bin目录下：
#!/bin/bash
./stopServer.sh server1
sleep 5
./startServer.sh server1
sleep 5是等待几秒确保进程完全退出，否则端口可能没释放，启动会失败。你也可以用while循环检查端口是否释放，更保险。
如果你在集群环境里，重启单个节点时最好先从集群成员中把节点摘掉，避免影响流量。通过管理控制台或者wsadmin.sh命令操作，等节点完全空闲了再重启，这样对用户的影响降到最低。
WAS的启动命令看似简单，但实际生产环境中遇到的问题千奇百怪。从环境变量到端口冲突，从权限配置到集群同步，每一步都可能卡住。掌握这些命令和排查思路，你在Linux上管理WAS就会顺手很多。
