上个月在机房同事火急火燎找我“BMC web页面崩了登录进去点两下就session expired进不到KVM想重启机器都没法点。”这种场景跑过机房的人应该都不陌生。管理卡网页白屏、登录被踢、session expired连环弹尤其是基于openbmc的IPMI管理页面排查起来经常让人一头雾水。我的习惯是不急着在浏览器里反复刷新而是直接回到Ubuntu工作机上用ipmitool把BMC从带外通道翻个底朝天。这篇文章记录的就是这套处理流程如何用ipmitool判断BMC的真实状态、定位web会话失效的根因把页面从“崩溃与session expired”的循环里拉回来。适合搞过服务器运维、调试过openbmc开发板或者正在被BMC web困扰的人参考。1. 故障现场与背后的机制session expired不一定是浏览器问题1.1 现场白屏、反复登录、session expired连环上演先说最常见的故障画像。BMC的web管理页面是运营维护和硬件调试的重要入口基于openbmc的设备通常会提供一套Web UI一般是phosphor-webui这类前端登录后可以看传感器、SEL日志、电源控制甚至通过虚拟KVM接管主机屏幕。这套页面一旦出问题外在表现往往是这几种浏览器访问BMC IP页面长时间白屏F12 看到一堆请求超时或 5xx登录成功后跳转一会儿就直接弹 session expired刷新几次偶尔能进去但点击任何菜单都触发重新登录多个管理员同时登录时一批人陆续被挤掉。很多人第一反应是“浏览器缓存问题”“flash被禁了”“换Chrome试试”但清缓存、换浏览器、换电脑都没用。这类问题如果只在前端折腾大概率白费功夫。它真正的根子通常在BMC自身的会话管理、后台服务状态或者带外网络的连通性上必须换一条路去查。1.2 openbmc的web会话是怎么工作的为什么会有session expiredopenbmc是基于Linux的BMC固件方案web页面不是像老式BMC那样靠Java插件或独立CGI硬撑而是走一套比较现代的前后端分离架构。前端UI通过HTTPS调用BMC上的Redfish API默认443端口路径是/redfish/v1后端常由bmcweb这类服务提供RESTful接口。你登录时输入用户名密码后端验明身份后签发一个session token后续每个请求都带着这个token直到session超时或被服务端主动清掉。session expired这个提示拆开看就是浏览器持有的token被BMC服务端认定为失效了或者前端与后端之间的会话状态丢了。触发原因一般有几类session超时时间太短页面挂着不动超过阈值token自然过期bmcweb服务重启过内存里的session表被清空旧token全部作废session数量打满新登录把旧session挤掉或者新的请求无法创建会话浏览器和BMC之间的TCP链路存在闪断导致登录后的请求根本没到BMCBMC系统时钟跳变、存储分区写满导致token校验逻辑异常。所以“session expired”只是一个结果不是病灶本身。排查方向应该先锁定是服务端session管理出了问题还是网络链路问题还是BMC本身已经在亚健康状态。这也是ipmitool这类带外工具的价值——web挂了不要紧只要BMC的IPMI通道还通就能从外面把状态摸清楚甚至直接把BMC复位救回来。1.3 为什么优先用带外工具而不是厂商专用软件遇到BMC web故障很多人习惯先找厂商管理工具或者等厂商技术支持远程。但实际运维中厂商工具不一定装得上授权不一定到位现场也不一定有外网。ipmitool是Linux下很成熟的IPMI命令行工具基于IPMI标准协议和BMC通信不依赖web界面也不依赖厂商私有实现Ubuntu的软件源里直接就有安装简单命令直观。最关键的是它在带外通道上仍然可用哪怕BMC的web服务彻底起不来只要BMC自身还在运行、IPMI LAN口还通就能完成绝大部分排查和恢复操作。2. 环境准备Ubuntu下ipmitool的安装与两种访问通道2.1 安装ipmitool一条命令的事在Ubuntu上安装ipmitool非常简单sudo apt update sudo apt install ipmitool -y装完之后先确认版本不同版本在部分命令参数上会有差异尤其涉及lanplus通道时老版本对新认证算法的支持不够理想。ipmitool -V一般能看到ipmitool utility version x.x.x。建议用较新的版本旧版连openbmc的BMC时偶尔会出现“Unable to establish IPMI v2 / RMCP session”的报错这跟BMC侧支持的认证算法有关换新版本通常能解决。如果apt源里的版本比较老也可以从源码编译但日常使用优先用系统包省事。2.2 本地KCS与远程lanplus两条路怎么选ipmitool和BMC通信有两条主要通路搞清楚这两条路的区别后面排查会顺很多。第一条是本地KCS通道。如果Ubuntu机器本身就是带BMC的服务器宿主机内核加载了IPMI驱动后ipmitool可以不指定网络参数直接操作本机BMCsudo modprobe ipmi_msghandler sudo modprobe ipmi_devintf sudo modprobe ipmi_si ipmitool mc info这种方式走的是主机和BMC之间的KCS接口不占网络即使BMC的管理网口断了也能用。但前提是你人在机器边上或者能通过SSH登录到宿主机。我在机房现场排查时第一选择永远是先登到宿主机上走本地KCS因为少一层网络依赖。第二条是远程LAN通道也是本文场景下最常用的。当web挂了但你从办公位能ping通BMC IP时直接远程连ipmitool -I lanplus -H BMC_IP -U 用户名 -P 密码 mc info这里-I lanplus是指定用IPMI 2.0 RMCP协议走网络。需要注意用户名密码不要在命令行明文留存太久shell history和ps都会暴露临时用可以长期跑脚本建议用-p后面跟提示输入或配合环境变量。openbmc默认管理员账号通常是root具体以你们设备初始化配置为准。2.3 故障现场第一步确认BMC还活着用ipmitool排查web崩溃第一步不是急着去看SEL或者复位置而是先确认BMC本身的响应状态。我会依次跑这几个命令ping -c 4 BMC_IP ipmitool -I lanplus -H BMC_IP -U 用户名 -P 密码 mc info ipmitool -I lanplus -H BMC_IP -U 用户名 -P 密码 chassis statusmc info能看到BMC固件版本、厂商ID、设备ID等信息chassis status能看到主机电源状态和电源开关状态。如果mc info能正常返回说明BMC核心在运行、IPMI LAN通道是好的问题大概率出在web服务或者session管理上思路就可以往服务层走。如果mc info直接超时ping也是通的那说明BMC可能整体hang住了web崩只是表象更底层的东西已经不正常了这种时候直接考虑冷复位BMC后面会细说。如果你从远程连不上但能登录宿主机也千万别忘了本地KCS这条退路。很多时候BMC管理网口的IP配置被误改、或者交换机端口down了远程LAN通道会失联但本地KCS仍然能够操作可以先用本地通道查看BMC网络配置把管理口拉回来。3. 诊断三板斧用ipmitool查session、翻SEL、看传感器3.1 查用户、查锁定、查session占用web登录不了很多人第一反应是密码不对或者账号被锁。ipmitool可以快速确认用户侧有没有异常。ipmitool -I lanplus -H BMC_IP -U 用户名 -P 密码 user list ipmitool -I lanplus -H BMC_IP -U 用户名 -P 密码 channel getaccess 1user list会列出BMC上所有IPMI用户和ID管理员账号是否enable、是否有操作权限一眼就能看到。channel getaccess能看到通道的访问权限、IPMI Messaging是否开启。如果发现某个用户被disable或者Admin权限被改成只读那就先解决权限问题再考虑web层。但这里有个容易忽略的点web层的session和IPMI用户会话是两套机制。openbmc的web登录会走Redfish API创建session而IPMI用户的会话是RMCP层面的ipmitool的user list并不能直接列出web的session token。不过如果用户数量异常、或者存在大量重复session记录很可能说明有人在用脚本频繁登录web把session表打满了。这种情况从BMC侧看资源占用会比较高最后表现就是后来的登录请求被拒前端提示session expired。3.2 翻SEL日志找异常事件与watchdog痕迹SELSystem Event Log是BMC记录硬件事件和系统事件的地方查web崩溃的根因时SEL是非常关键的证据来源。ipmitool -I lanplus -H BMC_IP -U 用户名 -P 密码 sel list | tail -100 ipmitool -I lanplus -H BMC_IP -U 用户名 -P 密码 sel elistsel list是按编号倒序输出tail看最近事件sel elist会显示事件类型、传感器编号、触发值和时间戳。我一般重点看这些事件voltage相关告警电源或电压波动会导致BMC重启或服务异常temperature告警温度过高触发风扇策略和告警严重时BMC自身的温度保护会把部分服务降级watchdog事件如果watchdog被触发并复位说明BMC或host系统曾经hang过power unit事件电源模块故障会导致BMC供电不稳进而影响web服务sensor number对应的事件有时候能看到bmc自身相关的传感器告警。SEL里如果出现一大段时间空缺或者事件记录时间戳有大范围跳跃基本可以判断BMC经历过非正常复位。因为这些信息的日期时间是BMC自己维护的如果BMC时钟没有同步日志时间会非常跳跃这也是个隐患时间不准会影响后续分析。SEL记录本身不会直接告诉你“bmcweb崩溃了”但它是线索集合点。我接手过的几次session expired故障里有两次在SEL里翻出了power unit的瞬时失压事件BMC在几秒内重启过一次web服务跟着被重置所有session失效这就是根因。这种隐蔽硬件问题不看SEL很难定位。3.3 看传感器数据排除硬件过热/电源波动诱发BMC重启传感器数据是SEL的补充SEL告诉你“发生了什么”sensor list告诉你“现在是什么状态”。ipmitool -I lanplus -H BMC_IP -U 用户名 -P 密码 sensor list输出很多可以筛选一下ipmitool -I lanplus -H BMC_IP -U 用户名 -P 密码 sensor list | grep -E CPU|Temp|Volt|Fan|Power|PCH重点是看有没有传感器读数异常偏高/偏低或显示为na、Disabled。如果CPU温度已经逼近阈值或者风扇转速异常说明BMC可能因为热保护策略频繁调整系统负载上升bmcweb响应变慢web操作容易出现超时和session异常。这种情况的恢复手段不是单纯重启BMC而是要先处理散热或电源问题否则重置完过一阵又会复发。顺带说一句sensor list里如果看到一堆“No Reading”通常不是传感器坏了而是主机处于S5软关机状态部分传感器不上电读数这属于正常现象别被吓到。4. 恢复与根治从mc reset cold到SessionService参数调整4.1 快速恢复web可用性ipmitool mc reset cold注意事项如果通过上面三板斧确认BMC核心还是能响应的最直接、立竿见影的办法就是复位BMC。ipmitool提供两个复位级别ipmitool -I lanplus -H BMC_IP -U 用户名 -P 密码 mc reset cold ipmitool -I lanplus -H BMC_IP -U 用户名 -P 密码 mc reset warmcold是冷复位相当于BMC断电重启会把所有运行时状态清掉包括所有web session和临时数据也会重新初始化各个服务。warm是软复位相对温和一些但不一定能解决服务卡死的问题。所以当web已经崩到完全不可用我通常直接上cold。执行mc reset cold有几个必须知道的点它复位的是BMC不会重启主机系统业务虚机和进程不受影响复位期间BMC网络会短暂中断BMC IP会ping不通一般30秒到3分钟不等具体看固件启动速度复位之后所有web会话、SOL会话全部断开需要重新登录如果BMC还在承担风扇控制策略复位过程中部分平台的风扇可能会短时间拉高转速机柜里会突然很吵这是正常现象别慌复位前最好确认BMC IP是静态IP还是DHCP如果是DHCP复位后有可能拿到不同的IP远程操作前要有心理准备。我的习惯是reset之前先记录当前BMC的IP和主机状态reset后等待1~2分钟再ping一下确认BMC起来了。如果IP变了可以通过DHCP服务器日志或者物理串口找到新地址。4.2 如果reset完又复现从Redfish侧调整session超时与清理sessionmc reset cold能救急但如果根因是session超时配置太短或者session数被打满那复位完很快又会复现。这时候就需要更深一层调整session策略了。openbmc对外提供Redfish API其中SessionService可以管理session超时时间。在Ubuntu工作机上用curl就能操作curl -k -u 用户名:密码 https://BMC_IP/redfish/v1/SessionService/返回内容里能看到SessionTimeout字段单位是秒。有些设备默认只有600秒10分钟页面挂着看一会儿就可能过期。可以通过PATCH方式调整curl -k -u 用户名:密码 -X PATCH https://BMC_IP/redfish/v1/SessionService/ -H Content-Type: application/json -d {SessionTimeout: 1800}如果没有Redfish访问条件的旧版本openbmc也可以在BMC的SSH终端里找相应配置接口但不同版本差异较大建议优先用Redfish标准接口兼容性好。另外如果怀疑session数量过多可以用Redfish列出当前sessioncurl -k -u 用户名:密码 https://BMC_IP/redfish/v1/SessionService/Sessions/返回的JSON里会有当前所有session的Id和用户名看到大量遗留session时可以逐个DELETE清理也可以直接reset cold一次性清空。相比重启整个BMC清理session的动静小得多在业务敏感场景下更安全。4.3 更隐蔽的诱因bmcweb服务异常与带外日志排查有一类session expired是“token还在但请求总是失败”看起来像session问题实际是bmcweb服务本身处于半死状态。这时ipmitool能做的判断是BMC整体正常、网络正常但web服务响应异常。要进一步确认需要登录BMC的shell看服务状态和日志。很多openbmc设备默认开放SSH可以用root直接登ssh rootBMC_IP登录后常用这几个命令systemctl status bmcweb journalctl -u bmcweb --no-pager -n 200 df -h如果bmcweb服务处于failed或频繁重启的状态可以手动重启它systemctl restart bmcweb除了服务状态还要看BMC自身的存储分区。openbmc通常有多个分区web日志、冗余固件、rwfs数据分区如果写满会导致服务无法写入临时文件session持久化失败表现就是登录后很快expired。df -h看到/tmp或/var分区100%时就该清日志了journalctl --vacuum-size50M rm -rf /var/log/*.log.*注意删除BMC上的文件要非常谨慎只清理明确的日志或临时文件别动系统文件和配置。没有十足把握的时候宁可先重启服务也不要乱删。4.4 顺带用SOL确认主机系统状态防止误杀在动用BMC复位、电源重启这类操作前我强烈建议先通过SOLSerial Over LAN看一眼主机的串口输出确认主系统是不是真的还活着。有时候web的KVM功能没法用但SOL还是通的ipmitool一行命令就能接上ipmitool -I lanplus -H BMC_IP -U 用户名 -P 密码 sol activate看到的是主机的串口控制台输出。如果主机系统已经死机或者内核panicSOL上能看到卡死的堆栈或者什么都没有。如果SOL完全连不上说明BMC的SOL会话也被占用了可能出现的情况是别的管理员也在远程操作或者上一次sol会话异常没有被正常释放。这时候可以等一会儿再试或者按快捷键~.脱离会话。SOL的价值在于它能在不依赖KVM、不依赖web的情况下直接确认宿主机操作系统的状态。我之前处理过两次“web崩了同时主机也失联”的case都是通过SOL看到内核panic然后走BMC电源重启救回来的。如果只看web层会浪费大量时间。5. 实操中必须注意的坑与巡检建议5.1 一套可以抄走的巡检命令吃过几次亏之后我每次遇到BMC web问题都会按固定顺序把下面这些命令过一遍效率高很多。你可以直接存成脚本参数替换成自己的环境BMC192.168.1.100 USERroot PASSyourpass # 1. 网络层连通性 ping -c 2 $BMC # 2. BMC核心状态 ipmitool -I lanplus -H $BMC -U $USER -P $PASS mc info # 3. 主机电源状态 ipmitool -I lanplus -H $BMC -U $USER -P $PASS chassis status # 4. 最近SEL事件 ipmitool -I lanplus -H $BMC -U $USER -P $PASS sel list | tail -30 # 5. 关键传感器 ipmitool -I lanplus -H $BMC -U $USER -P $PASS sensor list | grep -E CPU|Temp|Volt|Fan|Power|PCH # 6. 用户与通道权限 ipmitool -I lanplus -H $BMC -U $USER -P $PASS user list ipmitool -I lanplus -H $BMC -U $USER -P $PASS channel getaccess 1这套组合能覆盖八成以上web故障场景的初判。如果全部正常但web还是进不去基本可以确定是bmcweb层的问题按第4.3节的思路登录BMC shell去查journalctl。5.2 三个容易踩坑的地方第一不要把mc reset cold当成重启BMC服务的小操作。它会让BMC的管理网口短暂失联几分钟如果你当时是通过该BMC IP做远程操作比如连它的SOL连接会全部断开。还有有些BMC在复位后需要几分钟重载传感器数据期间传感器可能读到异常值别在复位后立刻判断硬件故障。第二执行复位前多看一遍chassis status和SEL确认主机电源当前是开着的。如果主机电源本身就是关闭状态复位BMC不至于误开机但有可能触发开机策略的变化。更安全的流程是先记录当前状态复位完再确认一遍避免被问“谁动了这台机器”时说不清楚。第三session expired不要只盯着一台BMC排查。如果同网段多台服务器的BMC同时出现web异常先怀疑网络和交换机比如管理网段广播风暴、BMC网口间冲突、或者交换机端口down。这种情况下ipmitool连BMC也会表现成时通时断你排查单机根因是在白费力气。5.3 最后聊点我在运维中形成的习惯处理BMC web类故障我现在反而觉得恢复服务只是第一步真正要做的是把根因记下来沉淀成一套检查单。像是session expired这种问题十次里有三次是bmcweb服务崩了两次是session表被脚本打满两次是BMC被复位过导致session集体失效剩下的才可能是网络、时间同步、硬件电压波动这些更隐蔽的原因。不把SEL和journal日志看完就盲目重置问题大概率还会回访。我个人的做法是每次处理后都把当时的关键命令输出保存下来文件名按日期加BMC型号命名放在团队共享的wiki目录里。下次再遇到类似问题先翻历史记录很多时候能直接命中根因省掉重复排查的时间。工具本身不难难的是一直保持“出了事后先取证再动手”的习惯。