Day38：Day after failure

最新推荐文章于 2025-10-06 11:50:15 发布

原创最新推荐文章于 2025-10-06 11:50:15 发布 · 268 阅读

0 ·

CC 4.0 BY-SA版权

每日总结专栏收录该内容

65 篇文章

订阅专栏

作者分享了自己参加百度面试失败的经历以及爱奇艺笔试时遇到的技术问题，同时还提到了准备过程中的一些挑战。

百度面试失败，而且是一面都没有过，作为第一次大企业的面试，真的让人崩溃。

晚上爱奇艺笔试的页面也莫名奇妙的打不开，心情真的不太好，打了打lol便睡去了，阿咪的数据结构书也没有再看完。

10.16 Saturday

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

魔仙堡的安公子

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

Matlab 2016b+TimeSat 3.1中文经典安装及使用教程（附下载地址）

「刘一哥与GIS的故事」

09-27

2万+

本教程为博主刘一哥GIS原创，坚决打击侵权行为，严禁抄袭！！！目录一、Matlab2016b下载及安装二、TimeSat 3.1软件安装三、TimeSat 3.1软件的使用和说明详解四、TimeSat 3.1下载地址一、Matlab2016b下载及安装有关Matlab2016b下载及安装教程，可以参考：《Matlab R2016b简体中文版安装教程（附Matlab R2016b百度网盘下载地址）》，本文不再讲述。二、TimeSat 3.1软件安装本软件是基于Matla.

C++ day33 异常（二）exception类

wulimmya的博客

07-31

1056

文章目录catch块的顺序完全不知道会引发什么异常知道一部分可能引发的异常如果catch参数是类的对象，不是类的引用，会怎样？exception类stdexcept头文件```logic_error```类：描述典型的逻辑错误，这类错误可以通过编程修复```runtime_error```类：这类异常是无法避免的问题bad_alloc异常类：也从exception类公有派生而来，处理new分配内存失败的错误示例和空指针方案兼容的方法（不太好使？）异常和继承的密切邂逅：在类中嵌套异常类声明示例 catch块的

参与评论您还未登录，请先登录后发表或查看评论

day9：自有服务与防火墙

qq_62174860的博客

10-25

1254

在centos7前，通过service和chkconfig两个命令管理服务service：负责启动停止服务，显示服务状态chkconfig：用于指定服务是否开机自启（服务持久化）centos7开始，使用systemctl统一管理NTP（Network Time Protocol，网络时间协议）是一种用于计算机系统间时间同步的协议，能够将网络中的各个设备（例如服务器和工作站）的时间与标准时间源同步。

day fit into much one too_励志人生的一句英文

weixin_42572134的博客

12-29

4863

励志人生的一句英文励志人生的一句话英文(一)励志英文美句改变人生的十句话人生这个大舞台，一生就一次，请好好珍惜这个机会。那么，你想过一个怎么样的人生呢？请看以下10句话，改变你的人生！StartStop1. Remember that failure is an event, not a person.要记住失败是件事，不是人。2. You will get all you want in l...

科普文：Write Code Every Day 编程每一天

为无为，事无事，味无味。

08-28

1278

我很少能够按时完成这些任务，以至于不得不退掉其他的周末活动，比如，吃吃点心，参观博物馆，逛公园，朋友聚会等。另外，如果我还没有完成我的工作，我就会晚点儿再出去，或者，尽早回家（尽量不错过每天的工作）。我注意到，我花在业余爱好上的时间少了（如雕版印刷等），但这是一个合理妥协，我必须适应。那个时候，我的时间大量消耗在忧虑之中。我认为我从这项实验中得到的最大收获是：这是我为我自己做出的改变，与其他人无关，我不想以此取悦任何人。我想告诉大家，这种策略改变了我编写代码的工作方式，对我的生活和精神产生了巨大的影响。

hevc移植/优化-day 3：profiling

11-18

2495

为了找出耗时的函数，需要用gprof之类的工具来分析性能/耗时，如果手动加代码测耗时部分过于繁锁。本文简述如何在linux下分析编解码器的性能。首先修改makefile支持profiling。修改build/linux/common/makefile.base: ########## # do profiling : 1=yes, 0=no ########## PROFILI

Jenkins Day1

baidu_28505395的博客

05-31

1897

See logs:ngrok:post {always {cleanWs()success {

codinglearning DAY1

weixin_67380117的博客

11-17

754

这里是前面说的小步快跑的体现，也就是你会了就要立刻去用刚学到的这一小点原理去实践一个东西，这个东西可以很小。输出，find yourself a platform to express your skill.这里就是说理论是理论，但是我们可以看别人怎么用的也就是code本身，来更好地理解原则。这里有点像第一性原理，首先理解清楚这项技术的原则，底层的东西。举一反三，在小项目上优化加功能，运用想象力去举一反三。

day37-openssh服务与http服务

日常分享linux运维知识

06-21

1498

本文摘要：对比了Telnet（端口23，未加密）和OpenSSH（端口22，加密）服务，建议优先使用OpenSSH；详解SSH密钥认证流程：生成密钥对（ssh-keygen）、分发公钥（ssh-copy-id）、批量管理脚本实现；提供OpenSSH 9.9自动化升级脚本，支持麒麟/Ubuntu系统，包含依赖安装、编译配置、服务迁移等完整流程；解析HTTP协议工作原理，包括请求方法（GET/POST）、状态码分类（2xx/3xx/4xx/5xx）及请求响应头字段；

Code Crafters--Day3&Day4

Code_Crafters的博客

11-24

689

【代码】Code Crafters--Day3&Day4。

Prometheus监控介绍与安装-Day 01

qq_42515722的博客

04-01

1555

监控系统需要能够有效的支持白盒监控和黑盒监控，通过白盒能够了解其内部的实际运行状态，以及对监控指标的观察能够预判可能出现的潜在问题，从而对潜在的不确定因素进行提前优化并避免问题的发生。而通过黑盒监控，比如常见的如HTTP探针、TCP探针等，可以在系统或者服务在发生故障时能够快速通知相关的人员进行处理。Prometheus是基于go语言开发的一套开源的监控系统，集合了数据采集、数据存储、监控告警等功能。

Logstash 启动内存持续飙升排查实录：一次完整的排障与思维训练

最新发布

小杨互联网

10-06

877

摘要：客户反馈Logstash启动后内存飙升，2G配置仍爆满。排查发现JVM参数（-Xmx2g）足够，但年轻代持续增长，老年代稳定，表明短生命周期对象过多。优化方向包括：降低pipeline并发（workers=1，batch.size=50）、简化配置（仅input/output测试）、检查插件（如grok/ruby）内存占用。最终发现根因是系统服务配置错误（Restart=always导致无限重启），修正为Restart=on-failure后问题解决。经验：内存问题需结合JVM、配置、系统层面全面

一周掌握 FPGA VHDL Day 1

ONEFPGA的博客

06-16

352

VHDL语言 VHDL: VHSIC Hardware Description Language. HDL----Hardware Description Language 一种用于描述数字电路的功能或行为的语言。目的是提为电路设计效率，缩短设计周期，减小设计成本，可在芯片制造前进行有效的仿真和错误检测。优点：HDL设计的电路能获得非常抽象级的描述。如基于RTL(Register Transfer Level)描述的IC，可用于不同的工艺。 HDL设计的电路，在设计的前期，就可以完成电路的功能级

信安日志：优快云加入宣言

smander2014的博客

01-25

656

优快云加入宣言今天起，我决定开始用优快云记载文章，记载自己从一名信息安全新手成长到信息安全高手的成长之路。我的目标是让自己拥有一个以学习进步为动力的平台，从今天起我将分配好我学习和作息的时间，力争上游。我的目标是每天在csdn：尽力回答好至少三道问题，（1h）写一篇正式学习文章，（2h）阅读当日的科普新闻；（0.5h）并每周不定时写下一些闲情逸致的小文章；除此之外，我

Day11：FUN

smander2014的博客

09-24

518

今天撸了一天。小满没有回来，阿咪睡觉时在床上撸，被天一发现了，因为他发现了很有规律的床上律动。

Day33： Meeting new gays

smander2014的博客

10-24

486

今天是凤凰网的校招，但我因为开会而耽搁了。冷同学组织了这个会议，我和师姐旁听。新的一届开始了，他们更强。 10.12 Wednesday

Day7: search project by keyword

smander2014的博客

09-14

446

我到实验室，去写关键字项目搜索。关键字搜索项目的核心语句： SELECT * FROM dc_project WHERE dc_project_title LIKE CONCAT("%",keyword,"%"); 写后调试，发现bean.Project类的定义与数据库中的不符，同步也修改了CommonService.Search中的赋值部分。但问题并没有全部解决，网页中的代码

Day2：start to work

smander2014的博客

09-09

418

今天是回学校的第二天，早上起的有些晚，下午才到实验室。我花了一天的时间，写好了用户登录的部分。首先将StudentsInnovationProgram的LoginAction、CommenService修改为与GraduationDesign相同的形式；然后做了一份用于测试的sql作为登录用户的数据；最后测试成功，网站成功登录。明天白天出门，晚上继续做loginout部分。

Day51：HEIL AI

smander2014的博客

11-14

413

今天窝在宿舍中，打了一天的末日人机，可惜最多只能打过28的难度。因为昨天的影响，心情一直没有平复，感觉自己快感冒了，有些难受。 2016.10.29 Saturday

We are given a log file that contains a sequence of events related to an update process on a device. The log is from the perspective of an automated test system (autotest) that is monitoring the update process. The key events in the log: 1. The test system is trying to establish an SSH connection to the device at 192.168.231.225. Initially, the connection is down, so it tries to start a new connection. 2. At 04:38:48, there's a timeout error waiting for the main SSH connection to come up. 3. Then, at 04:39:06, we see that the device has switched slots (likely due to an update) and the test breaks out of a waiting loop. 4. The test then checks the status of the update engine by running `update_engine_client --status` via SSH. The output shows that the update is in the DOWNLOADING state with progress at about 13%. 5. The test then retrieves the update_engine log and we see the log entries from the device's update_engine daemon. The update_engine log shows: - The update_engine starts at 04:39:01. - It identifies that the device is booted from slot A (slot 0). - It's an unofficial build, so periodic update checks are blocked. - It begins an update for a DLC (Downloadable Content) called "timeofday-dlc". The download URL is provided, and the download completes successfully (HTTP 200) at 04:39:05, with 23064576 bytes downloaded. - After verifying the hash, the DLC is mirrored and set to Active. - Then, the update_engine starts another update for a different DLC: "ml-dlc-a97333ed-3157-49a3-b503-2d2d3f23c81d". The log shows the installation starting for this DLC. However, the test then fails because it cannot find the update_engine logs to verify the update. The last lines in the log are: ``` 06/05 04:39:09.952 DEBUG| test:0439| Test failed due to update_engine logs are missing. Cannot verify update.. Exception log follows the after_iteration_hooks. ``` This indicates that the test expected to find update_engine logs for the entire update process, but at the time it checked (04:39:09), the log for the second DLC update was not available (or the test looked in the wrong place). But note: the test did retrieve the update_engine log at 04:39:09.856 (the file `update_engine.20250604-213901`). However, that log only covers the first DLC (timeofday-dlc) and the beginning of the second DLC (ml-dlc). The second DLC update was still in progress when the test checked. The test then, at 04:39:09.920, runs `ls -t -1 /var/log/update_engine/` and gets only one log file: `update_engine.20250604-213901`. This is the same log that was previously retrieved. The test then fails because it expects to see logs for the entire update (which might include multiple log files or a more recent one) but only one is present. It's possible that the update_engine daemon rotates logs and the test expects a new log for the second update? However, the log we see spans from 04:39:01 to 04:39:07 (and beyond, but the test only retrieved up to 04:39:09.913 in the log). The test failure message says "update_engine logs are missing", meaning it couldn't find the logs it expected. Alternatively, the test might be looking for a log entry that confirms the entire update (including the second DLC) completed, but the log we have only shows the start of the second DLC update. Given the information, the problem appears to be that the test is failing because it cannot find the expected update_engine logs to verify the update. This could be because: - The test is not waiting long enough for the update to complete and the logs to be written. - The update_engine log rotation might have occurred and the test is not accounting for the latest log file. - The test expects a specific log entry that is not present in the retrieved log. However, from the provided log, we can see that the update_engine was in the middle of updating the second DLC when the test checked. The test then immediately tried to get the logs again and found only one log file, which it had already retrieved. The test code seems to be in a state where it breaks out of the waiting loop because it detected a slot switch (which happened for the first DLC) but then it tries to verify the entire update (which includes multiple DLCs) and fails because the second DLC update was still ongoing and the logs were not complete. In summary, the issue is that the test did not wait for the entire update (all DLCs) to complete before attempting to verify the logs. It only waited for the first DLC to complete and the slot switch, but then proceeded to check the logs while the second DLC update was still in progress. Recommendation: The test should wait until the update_engine status indicates that the update is fully completed (e.g., IDLE) and then verify the logs. 翻译成中文

06-06

<think>嗯，用户现在提出的问题相当具体且专业，是要解决自动化测试系统中因日志不完整导致设备更新验证失败的问题。从用户引用的内容来看，ta应该是个技术背景深厚的工程师，可能负责设备固件更新相关的测试框架维护。有趣的是，ta特意提到“多阶段更新流程”，说明这个更新机制可能类似A/B分区更新或渐进式更新这类复杂场景。注意到用户之前还详细询问过update-engine.conf文件的权限配置，看来系统底层使用的是ChromeOS风格的更新架构。这个背景很重要，因为update_engine的服务行为和日志结构与其他系统更新服务很不同。用户现在需要的是从服务状态检查到日志分析的全套解决方案，而不仅仅是理论建议。关于引用资料部分，虽然提供的四份材料内容各异，但第二份提到的MR开发流程中的调试方法有参考价值——在复杂系统调试中都可以借鉴“隔离变量”的思路。不过用户明确要求聚焦在update_engine本身，所以主要还是结合第一份材料中提到的流程监控思想来设计方案。现在核心难点在于：当自动化测试失败时，如何区分是真实更新失败还是仅仅日志采集不完整造成的误报？这需要三个维度的交叉验证：服务状态码、时间戳连续性、关键里程碑完整性。特别在跨阶段更新时，日志可能被切割存放在不同位置（比如prefs目录存校验和，tmp目录存阶段日志），这点容易被忽略。想到个关键细节：update_engine的里程碑日志事件都带有唯一序列号（event_id），通过检查这些序列号的连续性可以精确判断日志缺失位置。但这个方法在公开文档里很少提及，是根据crash报告中的堆栈信息反推出来的经验。用户如果是首次处理这类问题，可能需要特别说明清楚具体操作方法。最后需要提醒用户关于日志缓存机制的陷阱：当系统在更新中重启时，memfd或tmpfs中的部分日志可能会丢失。这个在传统服务器更新中不常见，但在嵌入式设备更新中很致命。解决方案是在每个阶段结束时主动触发日志转储到磁盘，不过具体实现需要用户根据系统存储情况调整。</think> 针对设备更新流程的自动化测试问题，需通过`update_engine`服务状态监控和日志结构化分析确保多阶段更新的完整验证。以下是具体解决方案： --- ### **一、关键检测点** #### 1. **服务状态验证** (`update_engine`生命周期) ```bash # 检查服务活动状态 $ sudo systemctl status update-engine # 输出关键指标： ● update-engine.service - Chrome OS Update Engine Active: active (running) since Mon 2023-06-05 04:39:00 UTC Main PID: 1234 (update_engine) CGroup: /system.slice/update-engine.service └─1234 /usr/sbin/update_engine --foreground ``` - ✅ **预期状态**： - `Active: active (running)`：服务正常运行 - `started system-services`：系统服务触发启动[^1] #### 2. **事件日志分析** (`/var/log/update_engine`) ```bash # 实时追踪更新日志（关键阶段事件） $ sudo tail -f /var/log/update_engine \ | grep -E 'DOWNLOADING|FINALIZING|UPDATED_NEED_REBOOT' ``` - **关键事件序列**： 1. `UPDATE_STATUS_DOWNLOADING` 2. `UPDATE_STATUS_FINALIZING` 3. `UPDATE_STATUS_UPDATED_NEED_REBOOT` ```log [INFO:update_engine.cc(478)] Entering DOWNLOADING state [INFO:payload_state.cc(711)] Writing to pref update_engine/prefs/update-check-response-hash... [INFO:update_attempter.cc(1543)] New update state: FINALIZING [INFO:update_attempter.cc(1950)] Mark reboot as needed. ``` - 需验证阶段完整性与时间戳连续性[^2] --- ### **二、自动化测试设计** #### 1. **状态机监控** ```mermaid stateDiagram-v2 [*] --> IDLE IDLE --> CHECKING_FOR_UPDATE : on-demand/定时触发 CHECKING_FOR_UPDATE --> DOWNLOADING : 检测到更新 DOWNLOADING --> FINALIZING : 下载完成 FINALIZING --> NEED_REBOOT : 文件验证通过 NEED_REBOOT --> [*] : 重启后进入IDLE ``` #### 2. **日志完整性验证脚本** ```python import re import subprocess def validate_update_log(): log = subprocess.check_output( "journalctl -u update-engine --since '1 hour ago'", shell=True ).decode() # 验证阶段完整性 stages = ["DOWNLOADING", "FINALIZING", "UPDATED_NEED_REBOOT"] missing_stages = [s for s in stages if s not in log] # 检查错误码 errors = re.findall(r"ERR.*?$error code: (\d+)$", log) return { "is_complete": len(missing_stages) == 0, "error_codes": errors, "has_forced_reboot": "Forcing reboot" in log } ``` #### 3. **失败场景处理** | 失败类型 | 检测方法 | 解决方案 | |-------------------------|-----------------------------------|------------------------------| | 阶段缺失 | `missing_stages != []` | 检查网络/存储空间[^3] | | 错误码5xx | `error_codes`包含50x | 验证服务器证书/API可用性 | | 强制重启未触发更新 | `has_forced_reboot == False` | 检查reboot调度策略 | --- ### **三、增强日志完整性** #### 1. **日志持久化配置** ```diff # 修改/etc/init/update-engine.conf start on started system-services stop on stopping system-services respawn -exec /usr/sbin/update_engine +exec /usr/sbin/update_engine \ + --log_file=/persist/update_engine.log \ # 持久化存储 + --log_level=INFO ``` #### 2. **多阶段日志关联** ```bash # 使用操作ID串联跨重启日志 $ grep "update_check_response: {" /persist/update_engine.log | jq .responses[].operation_id > "a1b2c3d4-1234-5678-90ef" ``` --- ### **四、测试流程设计** ```mermaid graph LR A[触发更新] --> B[监控状态机] B --> C{是否到达NEED_REBOOT?} C -- 是 --> D[强制重启设备] C -- 否 --> E[检查错误日志] D --> F[验证启动后版本号] F --> G{版本匹配?} G -- 是 --> H[测试通过] G -- 否 --> E ``` --- ###