背景把系统邮件通道修通（新 SMTPS 服务严格投递 + 发件人/收件人改写）后，一批原本就存在、只是以前没人收到告警的系统运维问题陆续”显形”——因为以前这些失败邮件发不出去或没人看，现在能正常送达了。本文汇总这几个独立但同源的问题。 问题一：logrotate 配置文件权限过宽被忽略现象：error: Ignoring rails because of bad file mode - must be 0644 or 0444 根因：某个 logrotate 配置文件权限是 755（…
分类详情
resultweb 分类
ResultWeb 测试超时（user_defined_timeout）机制分析报告 分析目标：ResultWeb 如何处理 user_defined_timeout 字段来取消/中止测试执行 总体流程概览 用户输入 user_defined_timeout（单位：分钟），通过 UI 或 API 提交 TimeoutDuration concern 将分钟转换为秒（* 60），写入 suites_hash[suite][:timeout] JobBuilder 将超时值编码进测试命令字…
测试 Worker 节点日志与结果清理问题分析报告背景测试环境由 200 多个相互独立的 Worker 节点组成，每个节点通过统一镜像构建后部署在云平台上。每个 Worker： 拥有独立的 20G 根分区 在本地生成各自的测试执行结果（存放于 /nas/results/executions） 各自运行一份同步进程，将结果同步到结果展示服务 各自运行一份定时清理程序，清理本地旧数据 本报告针对排查过程中发现的多个问题进行汇总分析。 问题一：Metricbeat 持续产生无效日志现象系统日志中持续出…
服务器内存耗尽宕机与资源调优分析一、事件概述前端服务器(CentOS 7 虚拟机,48GB 内存 / 24 vCPU / 5GB Swap,运行 Rails + Passenger + MySQL + NFS 挂载)发生整机卡死,SSH 无法连接、服务停止响应,最终通过硬重启恢复。排查后确认是内存耗尽(OOM)引发的连锁故障。 二、故障时间线 时间 事件 T0 起 一个日志归档服务进入崩溃重启循环(约 25 秒一次),持续 1.5 小时以上 T0+1.5h 内核出现 page…
背景原先有一个配置项同时承担了两个角色： 作为发件人（所有 mailer 的 default from） 作为收件人（部分管理通知的 to，以及页面上展示的联系邮箱） 迁移到新 SMTPS 服务后，发件人需要用专门的”通知邮箱”（notification 邮箱只用来发、不用来收），而收件人仍应保持原有的真实邮件列表。一个配置项承担两个相反角色会冲突，需要拆分。 方案将原配置项拆成两个语义清晰的配置： 原配置项（收件人）：保持为真实邮件列表（管理/团队列表） 新增发件人配置项：值为各环境…
背景迁移到新 SMTPS 服务后，发现生产环境持续产生退信： <某功能账号@example.com>: 550 5.7.54 Unable to relay recipient in non-accepted domain 排查发现：一个 CI 自动化（功能/脚本）账号在用户表里的邮箱是占位地址（@example.com），它持续自动发起大量测试，每个测试完成的通知都尝试发给这个占位邮箱 → 新邮件服务器严格拒绝往外部/无效域投递 → 每次都退信。 旧邮件服务器时期，往这类无…
ResultWeb Preparation Stage Failure — Root Cause AnalysisSummaryA CI Loop test execution failed immediately at the preparation stage. Theprepare_for_test.rb script produced zero log output, and ResultWeb received acallback reporting exit status -1. I…
背景ResultWeb 应用原本通过本机 Postfix 中继到旧邮件服务器（无认证、无 TLS）。由于旧邮件服务器计划停用，需要迁移到新的内网邮件服务（带认证 + 加密）。 应用发信走本机 Postfix（localhost:25），因此迁移主要在 Postfix 层完成，应用层只需调整发件人地址配置。 关于”协议”的澄清：原始需求写的是”SMTPS / 587”，但这两者其实矛盾——传统 SMTPS 是 465 端口的隐式 TLS，而 587 是提交端口、用 STARTTLS 显式…
DNS 故障引发 Passenger 进程拥塞事件分析一、事件概述一次手动重启服务器后,前端服务进程(Passenger)数量持续增长并超过配置上限(80),即使重新部署、重启服务也只能短暂缓解,几分钟后又恢复拥塞。内存充足(无 OOM 风险),但服务严重变慢、请求大量排队。最终定位为一台 DNS 服务器失效引发的连锁拥塞。 二、现象 Passenger 进程涨到 80(触顶 MaxPoolSize),请求队列持续累积(16 → 52 → 65 → 100) 重启 httpd 无效,几分钟后再次…