会话为什么会用满
Redfish 的会话数量有限：脚本应当显式创建并删除会话，异常退出的残留会逐步耗尽配额，最终表现为登录被拒——而从界面上看，只像是密码错了。批量采集前先弄清会话上限与清理策略，比事后手工删会话高效得多。
基本信息
| 创建 | 向会话集合 POST，返回会话 id 与令牌 |
|---|---|
| 使用 | 后续请求带令牌头，比每次基本认证更省会话 |
| 清理 | 会话结束时 DELETE 对应资源 |
| 残留原因 | 脚本异常分支没有执行清理 |
| 排查入口 | 登录失败时先查看会话列表 |
| 配额差异 | 会话上限因厂商与固件版本而异 |
| 并发建议 | 按上限留出余量，避免影响到其它运维工具 |
典型使用场景
- 批量采集：用受限并发覆盖多台设备，避免挤占会话
- 排障：登录被拒时先确认是否存在残留会话
- 自动化加固：给脚本加上异常退出时的清理逻辑
- 监控接入：长周期采集复用同一会话并处理续期
- 文档交接：把会话上限与清理方法写进运维说明
- 巡检：观察会话数量趋势，提前发现泄漏
- 故障演练：模拟脚本异常退出，验证清理逻辑是否真的生效
会话管理与清理
会话管理与清理
# 查看当前会话列表
curl -k -s -u admin:'<口令>' https://<bmc-ip>/redfish/v1/SessionService/Sessions | head -40
# 删除残留会话（id 按实际列表替换）
curl -k -s -X DELETE -u admin:'<口令>' https://<bmc-ip>/redfish/v1/SessionService/Sessions/<id>
# 查看会话服务配置与超时设置
curl -k -s -u admin:'<口令>' https://<bmc-ip>/redfish/v1/SessionService | head -20会话字段读法
| 字段 | 含义 | 关注点 |
|---|---|---|
| Id | 会话标识 | 清理时按它删除 |
| UserName | 创建者账号 | 定位是哪个工具留下的 |
| CreatedTime | 创建时间 | 长期存在多为残留 |
| SessionTimeout | 超时设置 | 过短会导致长任务中断 |
| 令牌 | 创建响应中返回 | 后续请求带上即可复用 |
长周期采集复用同一会话并处理续期，比反复创建更稳，也少踩会话上限。
脚本异常退出不清理会话，是会话耗尽最常见的成因：把清理逻辑放进异常分支，比事后手工删更省事。