watchdog杀死system_server导致系统重启问题分析流程

最新推荐文章于 2025-05-15 13:28:47 发布
原创 最新推荐文章于 2025-05-15 13:28:47 发布 · 9.1k 阅读 · 23 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#watchdog

本文记录了一次monkey测试中系统因watchdog杀死ActivityManager线程引发的系统重启问题的分析过程。问题源于monkey在写bugreport文件时，由于连续的ANR或崩溃，导致写文件耗时过长，使得AMS的appCrashed方法被阻塞，最终系统重启。这是一个由monkey测试本身的IO操作引起的持锁过久问题，不需特别解决。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

下面是最近在解一个monkey测试过程中系统重启的bug的分析过程，从这里我们可以看一下对于watchdog杀死死锁进程的一般分析流程。（这里当是一个笔记，没有详细按着文章的逻辑来整理词汇和语句 汗汗汗）

1. watchdog: Blocked in handler on ActivityManager (ActivityManager)
      说明ActivityManager这个线程被blocked了（ActivityManager是system_server的一个线程）

  
2. 查看ActivityManager线程的堆栈状态：
  "ActivityManager" prio=5 tid=15 Blocked
  at com.android.server.am.ActivityManagerService$MainHandler.handleMessage(ActivityManagerService.java:1784)
  - waiting to lock <0x1a4c832a> (a com.android.server.am.ActivityManagerService) held by thread 61
  该线程在等待锁<0x1a4c832a>，这个锁被thread 61所持有
最低0.47元/天 解锁文章

200万优质内容无限畅学
Android 系统中的 WatchDog 详解
私房菜
07-12 2万+
Watchdog字面上是“看门狗”的意思，有做过嵌入式低层的朋友应该知道，为了防止嵌入式系统MCU里的程序因为干扰而跑飞，专门在MCU里设计了一个定时器电路，叫做看门狗。当MCU正常工作的，每隔一段时间会输出一个信号给看门狗，也就是所谓的喂狗。如果程序跑飞，MCU在规定的时间内没法喂狗，这时看门狗就会直接触发一个reset信号，让CPU重新启动。在Android系统的framework中，设计了一个系统服务Watchdog，它类似于一个软件看门狗，用来保护重要的系统服务。
Android Log分析-系统重启
Jimmy的专栏
05-23 3757
对Linux内核来说，Oops就意外着内核出了异常，此时会将产生异常时CPU的状态，出错的指令地址、数据地址及其他寄存器，函数调用的顺序甚至是栈里面的内容都打印出来，然后根据异常的严重程度来决定下一步的操作：杀死导致异常的进程或者挂起系统。，libwebcore.so是带符号表的so，位于/out/target/product/sp8830ec/symbols/system/lib，000b852a是对应的出错地址。，看开机的模式，如果没有则默认为normal mode，正常开机；
Watchdog 杀掉系统进程重启问题分析
ngRoom
05-31 1999
问题背景： 设备采用全志T3芯片，Android4.4系统。 在对相册等APP进行压测时，通过录像发现设备在21:55左右重启了。 问题分析： 我们抓取了logcat日志，内核日志，trace日志以及tomstorm日志。 logcat日志中我们发现是watchdog杀掉了系统进程导致系统重启的。 05-30 21:54:58.776 W/Watchdog( 2190): *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in monitor com.a
嵌入式设备watchdog导致reboot
weixin_58458700的博客
05-05 1615
在一般的嵌入式设备上都会有 hardware watchdog存在，它的意义是当你系统发生异常情况的时候，可以让你的嵌入式设备进行自动重启，而不是阻塞在被卡住的位置，如果系统在没有watchdog的情况下，Linux 发生Panic的时候，也可以触发自动重启。目前我们的嵌入式设备遇到了自动重启的问题，但是没有panic的Log，所以怀疑是Watchdog没有定期喂狗造成的重启。所以需要伪造一个坏境，让watchdog异常。
一次CloudLinux服务器频繁重启问题的排查与解决
最新发布
aiwo1337的博客
05-15 55
在为客户维护一台CloudLinux服务器的过程中，我遇到了一起频繁自动重启的疑难问题。尽管先后尝试了内核升级、Watchdog禁用和系统日志分析等软件层面的排查手段，问题依然存在。最终，通过检查BMC日志与硬件实地检修，发现主板CPU区域存在焦糊现象，CPU过热保护频繁触发是重启的根本原因。更换主板并重新配置网卡后，服务器恢复稳定运行。本文完整记录了故障排查流程，供运维人员参考借鉴。
Android模块编译push framework/service 等需要重启的模块之后，只要 kill system_server 就可以生效
zhangqi6627的专栏
08-03 444
目前 framework/base/services 验证有效
SystemServer 中的 WatchDog
Lud的博客
04-07 1371
文章目录启动 WatchDogWatchDog 监控的服务和线程WatchDog 实现原理 对于系统而言，大家都希望一直不出问题，但是很难保证一点不出问题。一但出问题，重启可以解决大部分的问题，因此最简单的办法是检测到了系统不正常了重启设备就好了。WatchDog 看门狗就是用来监测系统是否出问题而诞生的。工作原理是：软件系统必须定时像看门狗硬件中写入值来表示自己没出故障，俗称喂狗；否则超过了时间没有写入数据则重启设备。Android 的SystemServer 是一个复杂的进程，它启动了几十种服务，是最
Watchdog kills system service in system_server
zirconsdu的专栏
10-12 7766
本文描述由Watchdog杀掉系统服务而引起sysytem_server退出的issue, 并简要介绍Watchdog机理和简短记录ServerThread的looper线程. This watchdog issue is a very very common issue. The root cause is that service is blocked on something and i
案例1-CarService频繁crash导致system_server watchdog超时
weixin_44901612的博客
01-14 416
等到下次开机，用户解锁时 UsageStatsService 又会将这些记录从持久化存储读出来通过 android.bg 线程进行分发，假如一条记录需要 1ms，100000 条记录就需要 100s，这样就会导致 android.bg 线程持锁 mLock 一直处理消息，其他线程无法拿到 mLock 触发 system_server Watchdog 超时重启，而且重启设备也无法生效；UsageStatsService 会将事件封装为 Event：包含事件类型，包名和时间戳。
服务器无征兆异常重启
abc2116146的博客
08-05 1891
针对服务器无异常，无征兆，BMC无告警的情况下，服务器开机进入系统后，固定（10~30）分钟无限重启说明选项Os boot watchdog timer是否启用服务器watchdog功能(开启后，会通过Os boot watchdog timer timeout选项的配置，固定时间检查os系统中是否存在watchdog进程)enabled/disabledOs boot watchdog timer policy如果无法检测到watchdog进程，会对服务器执行的操作Power off / reset /d
关于 W/Watchdog( 1931): *** WATCHDOG KILLING SYSTEM PROCESS: null 处理
AndyTsui的专栏
01-26 3987
<br /> means that the system_server process deadlocked or failed to make<br />> progress for one minute.  When that happened, the watchdog also sent a<br />> SIGQUIT (signal 3) to the system process to cause it to write a stack<br />> dump of all Dalvik th
SystemServer中的WatchDog
u013234805的专栏
04-30 1598
对手机系统而言，因为肩负着接听电话和接收短信的“重任”，所以被寄予7x24小时正常工作的希望。但是基于成本，普通的手机系统很难做到完全不出故障。但是大部分的故障都会做重启后消失，不会影响继续使用。所以简单的办法是，如果检测到系统不正常了，将设备重新启动，这样用户就能继续使用了。那么如何才能判断系统是否正常呢。通常的做法是在设备中增加一个硬件看门狗，软件系统必须定时的向看门狗硬件中写值来表示自己没出
systemserver watchdog
08-01 743
watchdog 即看门狗，用来监测系统是否发生了死锁，无响应等问题。要定时喂狗，不及时喂狗认为此时系统发生了blcok。
SystemServer的Watchdog
Invoker123的博客
11-26 1000
  在我们的认知中，Watchdog 是 Linux 系统一个很重要的机制，其目的是监测系统运行的情况，一旦出现锁死，死机的情况，能及时重启机器（取决于设置策略），并收集crash dump。在Android的SystemServer中，也存在一个Watchdog用来监控一些重要的线程，一旦这些线程长时间阻塞，就会杀掉SystemServer进程，导致Android重启。   Watchdog是一...
Android T(13) -- system_server 虚拟机中的 Watchdog
flagstaff's blogs
06-11 1387
Watchdog 在初始化完后，用户就可以使用它提供的接口来设置各种喂狗操作(monitor)了，注意了，此处的喂狗操作是并的关系，即任何一个喂狗操作(monitor)的失败都会造成system_server进程被 kill，它支持两种喂狗操作的的添加。这是添加一个喂狗操作的实例，它的作用则是监控当前进程的可用binder线程是否大于进程的最大支持的binder 线程数，即如果在看门狗的超时时间内依然没有可用的binder线程，那么也会触发系统重启。下面来看看 HandlerChecker 的类结构。
android system_server WatchDog简介
congqingbin的专栏
09-02 1481
android系统中SystemServer WatchDog的主要作用是监控SystemServer进程的运行状态,防止其卡住或者死锁。
Watchdog死锁实例分析
大爷曹爱coding
09-05 2447
watchdog死锁实例分析
android -- WatchDog看门狗分析
热门推荐
andyhuabing的专栏
03-26 1万+
android -- WatchDog看门狗分析 在由单片机构成的微型计算机系统中,由于单片机的工作常常会受到来自外界电磁场的干扰,造成程序的跑飞,而陷入死循环,程序的正常运行被打断,由单片机控制的系统无法继续工作,会造成整个系统的陷入停滞状态,发生不可预料的后果,所以出于对单片机运行状态进行实时监测的考虑,便产生了一种专门用于监测单片机程序运行状态的芯片,俗称"看门狗"。 在
system_server thread-8
03-20
<think>好的，我现在需要帮助用户解决关于system_server线程的问题，特别是thread-8的技术问题和日志分析定位。首先，我需要回忆一下system_server的作用和相关知识。system_server是Android系统中的一个核心进程，负责启动和管理各种系统服务，比如ActivityManagerService、WindowManagerService等。如果其中的某个线程出现问题，比如thread-8出现异常，可能会导致系统卡顿甚至崩溃。 用户提到了日志分析和定位，所以我应该考虑如何从日志入手。首先，常见的日志来源有logcat、traces.txt以及crash日志。用户提供的引用中提到了system_server_crash和WatchDog日志，这些都可能包含关键信息。例如，引用[2]提到Android 9系统卡死后查看system_server_crash日志，而引用[3]则提到WatchDog生成的traces文件。这些文件记录了线程堆栈信息，有助于定位问题。 接下来，我需要分析具体步骤。第一步是收集相关日志，包括logcat中的崩溃信息、traces文件和可能的ANR日志。然后，在日志中搜索“system_server”和“thread-8”的关键词，找到对应的错误堆栈。例如，在traces文件中可以查看thread-8的调用栈，确定其执行的任务。引用[3]中的traces文件就是由WatchDog生成的，可能包含死锁或长时间阻塞的信息。 然后，需要检查线程状态。如果thread-8处于BLOCKED或WAITING状态，可能涉及锁竞争或资源死锁。此外，还要看是否有异常抛出，比如NullPointerException，这可能在logcat中有记录。引用[4]提到了GC日志中的时间分析，虽然不直接相关，但系统服务的性能问题也可能与GC有关，需要综合考虑。 可能的原因包括死锁、某个系统服务处理超时、或资源泄漏。例如，如果thread-8负责处理Binder通信，长时间阻塞可能导致WatchDog触发，如引用[3]中的情况。或者，如引用[1]所述，system_server在启动时fork出现问题，但用户的问题更侧重于运行时的线程问题。 最后，解决方案部分需要指导用户如何定位具体原因，比如分析堆栈、检查锁竞争、使用调试工具等。同时，生成的相关问题应涵盖日志分析、WatchDog机制、线程优化和常见崩溃场景，帮助用户进一步学习。 需要确保回答符合用户的要求，使用中文，正确应用引用标记，并生成相关问题。同时，注意LaTeX格式的正确使用，尽管在技术问题中可能较少涉及数学公式，但如果有变量或代码，需正确格式化。</think>### system_server线程相关问题分析与定位步骤 #### 1. 日志收集与初步筛选 - **关键日志来源**： - **logcat崩溃日志**：搜索`system_server`进程的崩溃记录，例如`FATAL EXCEPTION`或`ANR`信息[^2]。 - **traces.txt文件**：位于`/data/anr/`目录，记录线程堆栈信息，如`traces_SystemServer_*.txt`[^3]。 - **WatchDog日志**：当系统检测到服务阻塞时，会生成包含线程状态的文件[^3]。 示例日志片段： ``` "system_server" prio=5 tid=8 Native | group="main" sCount=1 dsCount=0 flags=1 obj=0x12c00000 self=0x7f8a3c0000 | sysTid=2197 nice=-2 cgrp=default sched=0/0 handle=0x7f8e4cb4a0 | state=S schedstat=( 12345678 9876543 123 ) utm=12 stm=5 core=1 HZ=100 ``` #### 2. 定位thread-8的具体任务 - **查看线程名称与堆栈**： - 通过`traces.txt`确认`thread-8`所属的系统服务（如`ActivityManager`、`WindowManager`等）。 - 示例堆栈分析： ```python # traces.txt片段 "thread-8" daemon prio=5 tid=8 Blocked at com.android.server.am.ActivityManagerService.someMethod(...) - waiting to lock <0x12345678> (a java.lang.Object) ``` 此处显示线程因锁竞争被阻塞[^3]。 #### 3. 常见问题场景与分析方法 - **死锁/锁竞争**： - 检查线程是否在`waiting to lock`某资源，且该资源被其他线程占用。 - 使用`jstack`或`kill -3`主动生成堆栈快照。 - **系统服务超时**： - 若涉及`WatchDog`日志，检查是否有服务未按时响应心跳（默认超时1分钟）。 - **CPU/内存资源耗尽**： - 结合`user/sys/real`时间分析（参考GC日志分析方法[^4]），确认是否因高负载导致线程阻塞。 #### 4. 解决方案与工具 - **锁竞争优化**： - 使用`synchronized`替换为`ReentrantLock`并设置超时。 - 通过`StrictMode`检测主线程耗时操作。 - **WatchDog机制规避**： ```java // 在服务中定期喂狗 Watchdog.getInstance().poke(); ``` - **性能分析工具**： - **systrace**：分析线程调度与CPU占用。 - **Android Profiler**：监控内存泄漏与线程状态。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值