Service 'zygote' killed by signal 1

一、问题描述

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 位机器

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
这里写图片描述

可以看到相同 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 位机器

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
这里写图片描述

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)

你可能感兴趣的:(Service 'zygote' killed by signal 1)