Service 'zygote' killed by signal 1

其他 2018-06-20 13:07:41 阅读次数: 2

一、问题描述

01-07 21:57:03.228 1690 2829 D ActivityManager: cleanUpApplicationRecord -- 5762
01-07 21:57:03.232 1690 1702 W WindowManager: Attempted to remove non-existing token: android.os.Binder@333a888
01-07 21:57:03.233 1690 2829 W ActivityManager: Scheduling restart of crashed service com.android.statementservice/.DirectStatementService in 60923ms
01-07 21:57:03.234 2892 3105 E WtProcessController: Error pid or pid not exist
01-07 21:57:03.234 1690 3683 D ActivityManager: cleanUpApplicationRecord -- 5324
01-07 21:57:03.235 1690 3683 I AutoStartManagerService: MIUILOG- Reject RestartService packageName :com.android.email uid : 10064
01-07 21:57:03.236 2892 3105 E WtProcessController: Error pid or pid not exist
01-07 21:57:03.236 1690 2876 D ActivityManager: cleanUpApplicationRecord -- 5303
01-07 21:57:03.237 1690 2876 I AutoStartManagerService: MIUILOG- Reject RestartService packageName :com.miui.personalassistant uid : 10040
01-07 21:57:03.303 10500 10500 W init : type=1400 audit(0.0:2272): avc: denied { write } for name="zygote64_pid" dev="debugfs" ino=12729 scontext=u:r:init:s0 tcontext=u:object_r:debugfs_ktrace:s0 tclass=file permissive=0
01-07 21:57:03.311 739 739 I cnss-daemon: RTM_NEWNEIGH message received: 28
01-07 21:57:03.311 739 739 E cnss-daemon: Stale or unreachable neighbors, ndm state: 32
01-07 21:57:03.314 553 553 I ServiceManager: service 'media.camera' died
01-07 21:57:03.314 553 553 I ServiceManager: service 'media.player' died
01-07 21:57:03.314 553 553 I ServiceManager: service 'media.resource_manager' died
01-07 21:57:03.317 730 980 E OMXNodeInstance: !!! Observer died. Quickly, do something, ... anything...
01-07 21:57:03.373 553 553 I ServiceManager: service 'media.radio' died
01-07 21:57:03.373 553 553 I ServiceManager: service 'media.sound_trigger_hw' died
01-07 21:57:03.373 553 553 I ServiceManager: service 'media.audio_flinger' died
01-07 21:57:03.373 553 553 I ServiceManager: service 'media.audio_policy' died
01-07 21:57:03.388 553 553 I ServiceManager: service 'fingerprints_service' died

1690 是重启之前的 system_server 的 pid，从上面的 log 中可以看出上一步 system_server 还在正常执行操作，下一步各种 service 就开始挂掉，系统开始重启了，中间也没有 system_server 的错误信息。这种情况下，我们会怀疑是其他 service 挂掉直接或间接导致 system_server 重启，譬如说 SurfaceFlinger 重启导致 system_server 重启；查看 log 可以发现 SurfaceFlinger 的 pid 并没有发生改变，并且：

u:r:zygote:s0                  root      1375  1     1613000 25752 20    0     0     0     fg  poll_sched 0000000000 S zygote
u:r:zygote:s0                  root      10500 1     2175000 92232 20    0     0     0     fg  poll_sched 0000000000 S zygote64

service zygote 的 pid 发生了变化，很容易可以推断出 zygote64 发生了重启，并导致 system_server 重启，搜索 log 果然可以发现：

<13>[ 9907.324247] init: Service 'zygote' (pid 1374) killed by signal 1
<13>[ 9907.324349] init: Service 'zygote' (pid 1374) killing any children in process group

zygote64 被 signal 1 杀掉了，那 signal 1 又是什么呢？我们可以通过 “kill -l” 进行查看：
这里写图片描述
signal 1 应为 SIGHUP

二、SIGHUP

从上面的分析可以看出，zygote64 是被 SIGHUP kill 了，下面来具体看一下 SIGHUP 是怎么产生的。
kernel/msm-4.4/kernel/exit.c

/*
 * Check to see if any process groups have become orphaned as
 * a result of our exiting, and if they have any stopped jobs,
 * send them a SIGHUP and then a SIGCONT. (POSIX 3.2.2.2)
 */
static void
kill_orphaned_pgrp(struct task_struct *tsk, struct task_struct *parent)
{
    struct pid *pgrp = task_pgrp(tsk);
    struct task_struct *ignored_task = tsk;

    if (!parent)
        /* exit: our father is in a different pgrp than
         * we are and we were the only connection outside.
         */
        parent = tsk->real_parent;
    else
        /* reparent: our child is in a different pgrp than
         * we are, and it was the only connection outside.
         */
        ignored_task = NULL;

    if (task_pgrp(parent) != pgrp &&
        task_session(parent) == task_session(tsk) &&
        will_become_orphaned_pgrp(pgrp, ignored_task) &&
        has_stopped_jobs(pgrp)) {
        __kill_pgrp_info(SIGHUP, SEND_SIG_PRIV, pgrp);
        __kill_pgrp_info(SIGCONT, SEND_SIG_PRIV, pgrp);
    }
}

可以看到在满足一系列条件时，会调用 __kill_pgrp_info(SIGHUP, SEND_SIG_PRIV, pgrp) 给 pgrp 中的每个进程发送一个 SIGHUP 信号，那么应该如何解读这些条件呢？

可以看到系统中有两处会调用到 __kill_pgrp_info(…) 函数，见下图：
这里写图片描述
我们先看一下5处 kill_orphaned_pgrp 的调用场景：
kernel/msm-4.4/kernel/exit.c

/*
 * This does two things:
 *
 * A.  Make init inherit all the child processes
 * B.  Check to see if any process groups have become orphaned
 *  as a result of our exiting, and if they have any stopped
 *  jobs, send them a SIGHUP and then a SIGCONT.  (POSIX 3.2.2.2)
 */
static void forget_original_parent(struct task_struct *father,
                    struct list_head *dead)
{
    struct task_struct *p, *t, *reaper;

    if (unlikely(!list_empty(&father->ptraced)))
        exit_ptrace(father, dead);

    // 为正在退出的进程查找其子进程的 reaper
    reaper = find_child_reaper(father);
    // 如果没有子进程，直接返回
    if (list_empty(&father->children))
        return;
    // 为正在退出的进程查找其子进程的新的 reaper
    reaper = find_new_reaper(father, reaper);
    list_for_each_entry(p, &father->children, sibling) {
        for_each_thread(p, t) {
            t->real_parent = reaper;
            BUG_ON((!t->ptrace) != (t->parent == father));
            if (likely(!t->ptrace))
                t->parent = t->real_parent;
            if (t->pdeath_signal)
                group_send_sig_info(t->pdeath_signal,
                            SEND_SIG_NOINFO, t);
        }
        /*
         * If this is a threaded reparent there is no need to
         * notify anyone anything has happened.
         */
        if (!same_thread_group(reaper, father))
            reparent_leader(father, p, dead);
    }
    list_splice_tail_init(&father->children, &reaper->children);
}

注意，这里传入的参数 father 实际上是 do_exit 中正在退出的 task 的指针，所以这个函数的主要作用是：

  • 为 father（也就是正在退出的 task）的每个子进程以及每个子进程的线程找到他们的新的父亲（real_parent）
  • 如果新的 reaper 与 father 不属于同一线程组，那么对 father 的每个子进程 p 调用 reparent_leader(father, p, dead) （注意这里的 father 并不是我们新找到的 reaper，仍旧是我们这个正在退出的 task）

kernel/msm-4.4/kernel/exit.c

/*
* Any that need to be release_task'd are put on the @dead list.
 */
static void reparent_leader(struct task_struct *father, struct task_struct *p,
                struct list_head *dead)
{
    if (unlikely(p->exit_state == EXIT_DEAD))
        return;

    /* We don't want people slaying init. */
    p->exit_signal = SIGCHLD;

    /* If it has exited notify the new parent about this child's death. */
    if (!p->ptrace &&
        p->exit_state == EXIT_ZOMBIE && thread_group_empty(p)) {
        if (do_notify_parent(p, p->exit_signal)) {
            p->exit_state = EXIT_DEAD;
            list_add(&p->ptrace_entry, dead);
        }
    }

    kill_orphaned_pgrp(p, father);
}

以上是第一处调用 kill_orphaned_pgrp 的地方，下面看一下第二处调用 kill_orphaned_pgrp 的地方：
kernel/msm-4.4/kernel/exit.c

/*
 * Send signals to all our closest relatives so that they know
 * to properly mourn us..
 */
static void exit_notify(struct task_struct *tsk, int group_dead)
{
    bool autoreap;
    struct task_struct *p, *n;
    LIST_HEAD(dead);

    write_lock_irq(&tasklist_lock);
    forget_original_parent(tsk, &dead);

    if (group_dead)
        kill_orphaned_pgrp(tsk->group_leader, NULL);

    if (unlikely(tsk->ptrace)) {
        int sig = thread_group_leader(tsk) &&
                thread_group_empty(tsk) &&
                !ptrace_reparented(tsk) ?
            tsk->exit_signal : SIGCHLD;
        autoreap = do_notify_parent(tsk, sig);
    } else if (thread_group_leader(tsk)) {
        autoreap = thread_group_empty(tsk) &&
            do_notify_parent(tsk, tsk->exit_signal);
    } else {
        autoreap = true;
    }

    tsk->exit_state = autoreap ? EXIT_DEAD : EXIT_ZOMBIE;
    if (tsk->exit_state == EXIT_DEAD)
        list_add(&tsk->ptrace_entry, &dead);

    /* mt-exec, de_thread() is waiting for group leader */
    if (unlikely(tsk->signal->notify_count < 0))
        wake_up_process(tsk->signal->group_exit_task);
    write_unlock_irq(&tasklist_lock);

    list_for_each_entry_safe(p, n, &dead, ptrace_entry) {
        list_del_init(&p->ptrace_entry);
        release_task(p);
    }
}

group_dead 是调用 exit_notify(…) 时传过来的参数，表明是线程组中最后一个退出的 task，tsk->group_leader 即 tgid，这就是第二处调用 kill_orphaned_pgrp 的地方

我们来比较一下两处调用 kill_orphaned_pgrp 的地方有什么不同，假设我们正在退出的 task 是 A（并且 A 是 group_leader 以及线程组中最后一个退出的 task），B 是 A 的子进程（由 A fork 出来），那么两处调用 kill_orphaned_pgrp 的地方分别为：

  • kill_orphaned_pgrp(B, A)
  • kill_orphaned_pgrp(A, NULL)

所以这两处调用 kill_orphaned_pgrp 的地方实际上是针对两种不同的情景：

情景一 kill_orphaned_pgrp(B, A) 如下图所示：
这里写图片描述
所以根据这幅图，可以这样理解 __kill_pgrp_info(SIGHUP, SEND_SIG_PRIV, pgrp) 前需要满足的四个条件：

  • task_pgrp(parent) != pgrp，进程 B 与他的 parent A 不处于同一 process group
  • task_session(parent) == task_session(tsk)，A 与 B 在同一 session 中
  • will_become_orphaned_pgrp(pgrp, ignored_task) (这里 ignored_task 为 NULL)，这个条件可以很形象地表示为 pgrp2 中除了进程 B 作为 process group 之间的桥梁之外，没有其他进程可以作为这样的桥梁（父进程是 init 的进程除外）
  • has_stopped_jobs(pgrp)，pgrp2 中有进程处于 stop 状态 （p->signal->flags & SIGNAL_STOP_STOPPED 为 true）

情景二 kill_orphaned_pgrp(A, NULL) 如下图所示：
这里写图片描述
根据这幅图，可以这样理解 __kill_pgrp_info(SIGHUP, SEND_SIG_PRIV, pgrp) 前需要满足的四个条件：

  • task_pgrp(parent) != pgrp，进程 A 与他的 parent 不处于同一 process group
  • task_session(parent) == task_session(tsk)，进程 A 与他的 parent 在同一 session 中
  • will_become_orphaned_pgrp(pgrp, ignored_task) (这里 ignored_task 为 A)，这个条件可以很形象地表示为 pgrp2 中除了进程 A 作为 process group 之间的桥梁之外，没有其他进程可以作为这样的桥梁（父进程是 init 的进程除外）
  • has_stopped_jobs(pgrp)，pgrp2 中有进程处于 stop 状态 （p->signal->flags & SIGNAL_STOP_STOPPED 为 true）

综合这上面两个情景，可以总结为，进程 A 退出时，会考虑会不会使得其子进程所处的 pgrp 变为孤儿进程组（情景一）以及会不会使得自己退出前所处的 pgrp 变为孤儿进程组（情景二）

三、实践

通过上面的分析，针对 __kill_pgrp_info(SIGHUP, SEND_SIG_PRIV, pgrp) 的两个场景，我们得出了很清晰的结论，下面就通过一些例子来验证一下我们的结论，理论与实践相结合，体验一下花式搞死 zygote 的快感

因为很多份 log 中，系统都是在一键清理 com.tencent.tmgp.speedmobile 这个应用的过程中挂掉的，我们就来看一下这个应用有什么过人之处（我们先在 32 位的机器上实践一下）：

1、32 位机器

这里写图片描述
可以看到相同 uid 有五个进程存在，我们再通过 cat /proc/pid/stat 和 cat /proc/pid/status 命令查看他们各自的 pid、ppid、pgid、sid 等信息，以 5999 为例，如下所示：
这里写图片描述
其中第一个数字是 pid，S 后面的三个数分别是 ppid、pgid、sid
这里写图片描述
通过上面两个命令，能列出上面5个进程之间的关系：

comm pid ppid tgid pgid sid
com.tencent.tmgp.speedmobile 5999 310 5999 5999 0
xg_service_v2 6076 310 6076 310 0
libxguardian.so 6199 1 6199 310 0
debuggerd 6274 5999 6274 6274 0
debuggerd 6276 6274 6276 310 0


默认情况下 zygote 进程的子进程和孙子进程（即所有 java 进程）的 pgid 应该都等于 zygote 进程的 pid，这里进程 5999 和 6274 应当是自己重新设置了 pgid；五个进程之间的关系如下图所示：
这里写图片描述
从上面五个进程之间的关系，以及前面分析得到的结论，我们可以推测：

  • pgrp 310 与其他 pgrp 沟通的桥梁可以认为有两个，分别是进程 C 和进程 E
  • 给 pgrp 310 中的某个进程发一个 stop 信号（kill -19），再 kill 进程 B 可以模拟出上面的情景一
  • 给 pgrp 310 中的某个进程发一个 stop 信号（除去进程 C），再 kill 进程 C 可以模拟出上面的情景二
  • kill 进程 B 或 C，给 pgrp 310 中的某个进程发一个 stop 信号（除去进程 C、E），再 kill 进程 E 可以模拟出上面的情景二

可以手动验证一下上面推测的三种情况，结论完美，O(∩_∩)O哈哈~

2、64 位机器

这里写图片描述
7个进程之间的关系：

comm pid ppid tgid pgid sid
zygote 709 1 709 709 0
zygote64 708 1 708 708 0
com.tencent.tmgp.speedmobile 5013 709 5013 5013 0
xg_service_v2 5101 709 5101 708 0
libxguardian.so 5201 1 5201 708 0
debuggerd 5232 5013 5232 5232 0
debuggerd 5234 5232 5234 708 0


默认情况下所有 java 进程（除去 zygote 进程）的 pgid 应该都等于 zygote64 进程的 pid，zygote 进程自己处于一个 pgrp 中，如上 7 个进程之间的关系如下图所示：
这里写图片描述
从上面几个进程之间的关系，以及前面分析得到的结论，我们可以推测：

  • pgrp zygote64 与其他 pgrp 沟通的桥梁可以认为有多个，分别是进程 C 和进程 E，以及 zygote 进程的子进程
  • kill zygote 进程的所有子进程（除去 A），给 pgrp zygote64 中的某个进程发一个 stop 信号（kill -19），再 kill 进程 B 可以模拟出上面的情景一
  • kill zygote 进程的所有子进程（除去 A），给 pgrp zygote64 中的某个进程发一个 stop 信号（除去进程 C），再 kill 进程 C 可以模拟出上面的情景二
  • kill zygote 进程的所有子进程，kill 进程 B 或 C，给 pgrp zygote64 中的某个进程发一个 stop 信号（除去进程 C、E），再 kill 进程 E 可以模拟出上面的情景二，注意这是理论上的，实际操作过程中由于 com.tencent.tmgp.speedmobile 的设置，kill 进程 D 的同时进程 E 也会挂掉
  • kill zygote 进程的所有子进程（除去 D 或者其他的任意一个进程 X），kill 进程 B 或 C，给 pgrp zygote64 中的某个进程发一个 stop 信号（除去会被 kill 的进程），再 kill 进程 D 或 X 可以模拟出上面的情景二

可以手动验证一下上面推测的几种情况，结论完美，^_^

综上所述，32位和64位机器相差的实际上就是 zygote 这个 process group，如果把 zygote 的子进程都 kill 掉，64位系统的进程关系实际上就相当于32位系统的进程关系；

可以发现，实际上在64位机器上，zygote 进程的子进程很少，大部分 java 进程都是 zygote64 的子进程，这样就很容易出现 zygote 进程的子进程都已经退出的状况了；

四、解决方案

为什么会产生 SIGHUP 这个机制可以参考博客 http://blog.csdn.net/zhangfangew/article/details/27070491
另外，已经就这个问题向 google 提交了 issue https://issuetracker.google.com/issues/71965619 和 change https://android-review.googlesource.com/c/platform/frameworks/base/+/588576

五、知识点补充

list_for_each(pos, head)、list_for_each_entry(pos, head, member)

猜你喜欢

转载自blog.csdn.net/u013989732/article/details/79167084
今日推荐
《美国对全球网络空间安全与发展的威胁和破坏》报告发布
火速冲上 GitHub 热榜 —— 开源编程语言、框架哪有这么可爱？
北京人形机器人创新中心发布全球首个纯电驱拟人奔跑的全尺寸人形机器人“天工”
LFOSSA 源来如此公开课 | 掌握云原生未来：CNCF 认证全面攻略与备考秘籍
国产云输入法——仅华为无云端数据上传安全问题
周排行
Python环境安装与基础语法（1）——计算机基础知识
IMU预积分
ADAS中的LDW、FCW、BSD、LCA、ACC、AEB、APA、DMS代表的含义
B站笔试两道题
skyeye arm 硬件虚拟机环境的搭建
Web前端静态页面示例
数组-合并排序数组 II-简单
springcloud之版本问题启动报错
面向对象-------------匿名对象(六)
输入URL到页面呈现中间发生了什么？
每日归档
更多
2024-04-30(1)
2024-04-29(40)
2024-04-28(0)
2024-04-27(56)
2024-04-26(39)
2024-04-25(22)
2024-04-24(36)
2024-04-23(26)
2024-04-22(39)
2024-04-21(0)

代码天地 © 2018 codetd.com

境外服务器   最新电视剧2022