概述
init是linux系统中用户空间的第一个进程。由于Android是基于linux内核的，所以init也是Android系统中用户空间的第一个进程，它的进程号为1。
作为系统中的第一个用户空间进程，init进程被赋予了很多及其重要的工作职责。
1. init进程创建系统中几个关键进程，例如zygote等。
2. Android系统有很多属性，于是init就提供了一个property service（属性服务）来管理它们。（这篇文章讲过 http://blog.csdn.net/hu3167343/article/details/38230271）
今天我们主要以第1点来详细说明下init进程的工作。
init进程的main函数
init进程的主要代码如下：
int main(int argc, char **argv)
{
int fd_count = 0;
struct pollfd ufds[4];
char *tmpdev;
char* debuggable;
char tmp[32];
int property_set_fd_init = 0;
int signal_fd_init = 0;
int keychord_fd_init = 0;
bool is_charger = false;
...
mkdir("/dev", 0755);
mkdir("/proc", 0755);
mkdir("/sys", 0755);
mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755");
mkdir("/dev/pts", 0755);
mkdir("/dev/socket", 0755);
mount("devpts", "/dev/pts", "devpts", 0, NULL);
mount("proc", "/proc", "proc", 0, NULL);
mount("sysfs", "/sys", "sysfs", 0, NULL);
...
// 属性服务初始化
property_init();
get_hardware_name(hardware, &revision);
process_kernel_cmdline();
// selinux安全机制初始化
union selinux_callback cb;
cb.func_log = klog_write;
selinux_set_callback(SELINUX_CB_LOG, cb);
cb.func_audit = audit_callback;
selinux_set_callback(SELINUX_CB_AUDIT, cb);
selinux_initialize();
/* These directories were necessarily created before initial policy load
* and therefore need their security context restored to the proper value.
* This must happen before /dev is populated by ueventd.
*/
restorecon("/dev");
restorecon("/dev/socket");
restorecon("/dev/__properties__");
restorecon_recursive("/sys");
is_charger = !strcmp(bootmode, "charger");
INFO("property init\n");
if (!is_charger)
property_load_boot_defaults();
// 解析init.rc配置文件
INFO("reading config file\n");
init_parse_config_file("/init.rc");
/*
解析完init.rc配置文件后，会得到一系列的Action，action_for_each_trigger函数用来执行early-init阶段的Action。
init将动作执行的时间划分为4个阶段：early-init、init、early-boot、boot。由于有些动作必须要在其他动作完成后才能执行，所以就有了先后之分。哪些动作属于哪个阶段由配置文件决定。
*/
action_for_each_trigger("early-init", action_add_queue_tail);
queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done");
queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
queue_builtin_action(keychord_init_action, "keychord_init");
queue_builtin_action(console_init_action, "console_init");
/* execute all the boot actions to get us started */
// 执行init阶段的动作
action_for_each_trigger("init", action_add_queue_tail);
/* skip mounting filesystems in charger mode */
if (!is_charger) {
action_for_each_trigger("early-fs", action_add_queue_tail);
action_for_each_trigger("fs", action_add_queue_tail);
action_for_each_trigger("post-fs", action_add_queue_tail);
action_for_each_trigger("post-fs-data", action_add_queue_tail);
}
/* Repeat mix_hwrng_into_linux_rng in case /dev/hw_random or /dev/random
* wasn't ready immediately after wait_for_coldboot_done
*/
queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
queue_builtin_action(property_service_init_action, "property_service_init");
queue_builtin_action(signal_init_action, "signal_init");
queue_builtin_action(check_startup_action, "check_startup");
// 执行early-boot和boot阶段的动作
if (is_charger) {
action_for_each_trigger("charger", action_add_queue_tail);
} else {
action_for_each_trigger("early-boot", action_add_queue_tail);
action_for_each_trigger("boot", action_add_queue_tail);
}
/* run all property triggers based on current state of the properties */
queue_builtin_action(queue_property_triggers_action, "queue_property_triggers");
#if BOOTCHART
queue_builtin_action(bootchart_init_action, "bootchart_init");
#endif
// 无限循环，用来处理各种消息
for(;;) {
int nr, i, timeout = -1;
execute_one_command();
restart_processes(); // 重启那些已经死去的进程
// 用来监听属性设置服务的事件
if (!property_set_fd_init && get_property_set_fd() > 0) {
ufds[fd_count].fd = get_property_set_fd();
ufds[fd_count].events = POLLIN;
ufds[fd_count].revents = 0;
fd_count++;
property_set_fd_init = 1;
}
if (!signal_fd_init && get_signal_fd() > 0) {
ufds[fd_count].fd = get_signal_fd();
ufds[fd_count].events = POLLIN;
ufds[fd_count].revents = 0;
fd_count++;
signal_fd_init = 1;
}
if (!keychord_fd_init && get_keychord_fd() > 0) {
ufds[fd_count].fd = get_keychord_fd();
ufds[fd_count].events = POLLIN;
ufds[fd_count].revents = 0;
fd_count++;
keychord_fd_init = 1;
}
if (process_needs_restart) {
timeout = (process_needs_restart - gettime()) * 1000;
if (timeout < 0)
timeout = 0;
}
if (!action_queue_empty() || cur_action)
timeout = 0;
#if BOOTCHART
if (bootchart_count > 0) {
if (timeout < 0 || timeout > BOOTCHART_POLLING_MS)
timeout = BOOTCHART_POLLING_MS;
if (bootchart_step() < 0 || --bootchart_count == 0) {
bootchart_finish();
bootchart_count = 0;
}
}
#endif
nr = poll(ufds, fd_count, timeout);
if (nr <= 0)
continue;
// 处理具体的消息
for (i = 0; i < fd_count; i++) {
if (ufds[i].revents == POLLIN) {
if (ufds[i].fd == get_property_set_fd())
handle_property_set_fd();
else if (ufds[i].fd == get_keychord_fd())
handle_keychord();
else if (ufds[i].fd == get_signal_fd())
handle_signal();
}
}
}
return 0;
}
从以上代码来看，init进程的工作量还是很大的，主要集中在如下几个事情：
1. 解析init.rc配置文件。
2. 执行各个阶段的动作，创建zygote的工作就是在其中的某个阶段完成的。
3. 初始化property service（属性服务）。
4. init进入一个无限循环，并且等到一些事情的发生。
解析init.rc
init的main函数主要是解析了init.rc文件，然后执行相应的初始化操作。我们先来看看init_parse_config_file函数的实现：
int init_parse_config_file(const char *fn)
{
char *data;
data = read_file(fn, 0); // 读取inic.rc文件的内容
if (!data) return -1;
// 开始解析
parse_config(fn, data);
DUMP();
return 0;
}
static void parse_config(const char *fn, char *s)
{
struct parse_state state;
struct listnode import_list;
struct listnode *node;
char *args[INIT_PARSER_MAXARGS];
int nargs;
nargs = 0;
state.filename = fn;
state.line = 0;
state.ptr = s;
state.nexttoken = 0;
state.parse_line = parse_line_no_op; // 设置解析函数，在android4.1上此函数为空
list_init(&import_list);
state.priv = &import_list;
// 开始解析init.rc文件内容，以行为单位
for (;;) {
switch (next_token(&state)) {
case T_EOF: // 文件末尾
state.parse_line(&state, 0, 0);
goto parser_done;
case T_NEWLINE: // 新的行
state.line++;
if (nargs) {
int kw = lookup_keyword(args[0]);
if (kw_is(kw, SECTION)) {
state.parse_line(&state, 0, 0);
parse_new_section(&state, kw, nargs, args);
} else {
state.parse_line(&state, nargs, args);
}
nargs = 0;
}
break;
case T_TEXT: // 文本内容，设置为args参数
if (nargs < INIT_PARSER_MAXARGS) {
args[nargs++] = state.text;
}
break;
}
}
parser_done:
list_for_each(node, &import_list) {
struct import *import = node_to_item(node, struct import, list);
int ret;
INFO("importing '%s'", import->filename);
ret = init_parse_config_file(import->filename);
if (ret)
ERROR("could not import file '%s' from '%s'\n",
import->filename, fn);
}
}
再来看看keywords.h对init.rc文件中关键字的定义
KEYWORD(capability, OPTION, 0, 0) KEYWORD(chdir, COMMAND, 1, do_chdir) KEYWORD(chroot, COMMAND, 1, do_chroot) KEYWORD(class, OPTION, 0, 0) KEYWORD(class_start, COMMAND, 1, do_class_start) KEYWORD(class_stop, COMMAND, 1, do_class_stop) KEYWORD(class_reset, COMMAND, 1, do_class_reset) KEYWORD(console, OPTION, 0, 0) KEYWORD(critical, OPTION, 0, 0) KEYWORD(disabled, OPTION, 0, 0) KEYWORD(domainname, COMMAND, 1, do_domainname) KEYWORD(exec, COMMAND, 1, do_exec) KEYWORD(export, COMMAND, 2, do_export) KEYWORD(group, OPTION, 0, 0) KEYWORD(hostname, COMMAND, 1, do_hostname) KEYWORD(ifup, COMMAND, 1, do_ifup) KEYWORD(insmod, COMMAND, 1, do_insmod) KEYWORD(import, SECTION, 1, 0) KEYWORD(keycodes, OPTION, 0, 0) KEYWORD(mkdir, COMMAND, 1, do_mkdir) KEYWORD(mount_all, COMMAND, 1, do_mount_all) KEYWORD(mount, COMMAND, 3, do_mount) KEYWORD(on, SECTION, 0, 0) KEYWORD(oneshot, OPTION, 0, 0) KEYWORD(onrestart, OPTION, 0, 0) KEYWORD(powerctl, COMMAND, 1, do_powerctl) KEYWORD(restart, COMMAND, 1, do_restart) KEYWORD(restorecon, COMMAND, 1, do_restorecon) KEYWORD(rm, COMMAND, 1, do_rm) KEYWORD(rmdir, COMMAND, 1, do_rmdir) KEYWORD(seclabel, OPTION, 0, 0) KEYWORD(service, SECTION, 0, 0) KEYWORD(setcon, COMMAND, 1, do_setcon) KEYWORD(setenforce, COMMAND, 1, do_setenforce) KEYWORD(setenv, OPTION, 2, 0) KEYWORD(setkey, COMMAND, 0, do_setkey) KEYWORD(setprop, COMMAND, 2, do_setprop) KEYWORD(setrlimit, COMMAND, 3, do_setrlimit) KEYWORD(setsebool, COMMAND, 2, do_setsebool) KEYWORD(socket, OPTION, 0, 0) KEYWORD(start, COMMAND, 1, do_start) KEYWORD(stop, COMMAND, 1, do_stop) KEYWORD(swapon_all, COMMAND, 1, do_swapon_all) KEYWORD(trigger, COMMAND, 1, do_trigger) KEYWORD(symlink, COMMAND, 1, do_symlink) KEYWORD(sysclktz, COMMAND, 1, do_sysclktz) KEYWORD(user, OPTION, 0, 0) KEYWORD(wait, COMMAND, 1, do_wait) KEYWORD(write, COMMAND, 2, do_write) KEYWORD(copy, COMMAND, 2, do_copy) KEYWORD(chown, COMMAND, 2, do_chown) KEYWORD(chmod, COMMAND, 2, do_chmod) KEYWORD(loglevel, COMMAND, 1, do_loglevel) KEYWORD(load_persist_props, COMMAND, 0, do_load_persist_props) KEYWORD(ioprio, OPTION, 0, 0)
Init.rc文件的主要内容如下（system\core\rootdir\init.rc）：
# Copyright (C) 2012 The Android Open Source Project
#
# IMPORTANT: Do not create world writable files or directories.
# This is a common source of Android security bugs.
#
import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.trace.rc
# 根据上面的分析可知，on关键字标示一个section，对应的名字为early-init
on early-init
# Set init and its forked children's oom_adj.
write /proc/1/oom_adj -16
# Set the security context for the init process.
# This should occur before anything else (e.g. ueventd) is started.
setcon u:r:init:s0
start ueventd
# create mountpoints
mkdir /mnt 0775 root system
…
# 又一个新的section，名为boot
on boot
...
# class_start是一个COMMAND，对应处理函数是do_class_start
class_start core
class_start main
…
# system server cannot write to /proc/sys files, so proxy it through init
on property:sys.sysctl.extra_free_kbytes=*
write /proc/sys/vm/extra_free_kbytes ${sys.sysctl.extra_free_kbytes}
## Daemon processes to be run by init.
##
service ueventd /sbin/ueventd
class core
critical
seclabel u:r:ueventd:s0
…
# 下面这个section的意思是，如果属性ro.kernel.qemu为1，那么执行相应的COMMAND ，# 即start adbd
on property:ro.kernel.qemu=1
start adbd
...
# service关键字也是一个SECTION，对应的SECTION名为zygote。
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
class main
socket zygote stream 660 root system
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
onrestart restart media
onrestart restart netd
service drm /system/bin/drmserver
class main
user drm
group drm system inet drmrpc
...
从上面对init.rc文件大致分析可知
1、 一个section的内容从这个标识section的关键字开始，到下一个标识section的地方结束。
2、 Init.rc中出现了名为early-init和boot的section，这里的early-init和boot就是前面介绍的4个动作执行阶段中的early-init和boot。也就是说在boot阶段执行的动作都是由boot这个section定义的。
另外，zygote被放在了一个service section中，下面以zygote这个section为例，具体介绍下service是如何解析的。
解析zygote 服务
Zygote对应的service section内容如下：
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
class main
socket zygote stream 660 root system
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
onrestart restart media
onrestart restart netd
解析section的入口函数是parse_new_section：
void parse_new_section(struct parse_state *state, int kw,
int nargs, char **args)
{
printf("[ %s %s ]\n", args[0],
nargs > 1 ? args[1] : "");
switch(kw) {
case K_service:
state->context = parse_service(state, nargs, args);
if (state->context) {
state->parse_line = parse_line_service;
return;
}
break;
case K_on:
state->context = parse_action(state, nargs, args);
if (state->context) {
state->parse_line = parse_line_action;
return;
}
break;
case K_import:
parse_import(state, nargs, args);
break;
}
state->parse_line = parse_line_no_op;
}
其中，解析service时，用到了parse_service和parse_line_service这两个函数，在介绍这两个函数之前，我们首先看看init是如何组织这个service的。
service结构体
struct service {
/*
用来连接所有的services。Init中有一个全局的service_list变量，专门用来保存解析配置文件后得到的service。
*/
struct listnode slist;
const char *name; // service的名字，在我们的例子中为zygote
const char *classname; // service所属的class名字，默认为default
unsigned flags; // service的属性
pid_t pid; // 进程号
time_t time_started; /* 上一次启动时间 */
time_t time_crashed; /* 上一次死亡时间*/
int nr_crashed; /* 死亡次数 */
uid_t uid;
gid_t gid;
gid_t supp_gids[NR_SVC_SUPP_GIDS];
size_t nr_supp_gids;
char *seclabel;
/*
有些service需要使用socket来通信，下面这个socketinfo用来描述socket的相关信息。
我们的zygote也使用了socket，配置文件中的内容是socket zygote stream 660 root system。
它表示将创建一个AF_STREAM类型的socket（其实就是TCP socket），该socket的名为zygote，读写权限是660。
*/
struct socketinfo *sockets;
// service一般运行在一个单独的进程中，envvars用来描述创建这个进程时所需的环境
// 变量信息。
struct svcenvinfo *envvars;
/*
虽然onrestart关键字是一个OPTION，可是这个OPTION后面一般都跟着一个COMMAND，action结构体就是用来存储command信息的。
*/
struct action onrestart; /* Actions to execute on restart. */
/* keycodes for triggering this service via /dev/keychord */
int *keycodes;
int nkeycodes;
int keychord_id;
// io优先级
int ioprio_class;
int ioprio_pri;
int nargs; // 参数个数
/* "MUST BE AT THE END OF THE STRUCT" */
char *args[1]; // 用于存储参数内容
};
了解了service结构，那么其中的action是怎么保存的呢，我们再来看看action结构体。
struct action {
/*
一个action结构可以被链入三个不同的双向链表中，其中alist用来存储所有的action，
qlist用来链接那些等待执行的action，tlist用来链接那些待某些条件满足后就需要执行的action。
*/
/* node in list of all actions */
struct listnode alist;
/* node in the queue of pending actions */
struct listnode qlist;
/* node in list of actions for a trigger */
struct listnode tlist;
unsigned hash;
const char *name; // 名字一般为"onrestart"
/*
一个command的结构列表，command结构如下：
struct command
{
/* list of commands in an action */
struct listnode clist;
int (*func)(int nargs, char **args);
int nargs;
char *args[1];
};
*/
struct listnode commands;
struct command *current;
};
解析parse_service
了解了关键的结构体之后，我们接下来看看parse_service函数的具体思路：
static void *parse_service(struct parse_state *state, int nargs, char **args)
{
struct service *svc;
// ….省略参数检测
// 根据服务名在全局服务链表service_list里面查找，如果已经有了，则返回
svc = service_find_by_name(args[1]);
if (svc) {
parse_error(state, "ignored duplicate definition of service '%s'\n", args[1]);
return 0;
}
// 分配service结构内存
nargs -= 2;
svc = calloc(1, sizeof(*svc) + sizeof(char*) * nargs);
if (!svc) {
parse_error(state, "out of memory\n");
return 0;
}
svc->name = args[1]; // 服务名，此处为zygote
svc->classname = "default"; // 设置classname为default，此处很关键
memcpy(svc->args, args + 2, sizeof(char*) * nargs); // 拷贝参数，此处拷贝的是字符指针
svc->args[nargs] = 0;
svc->nargs = nargs; // 保存参数个数
svc->onrestart.name = "onrestart";
list_init(&svc->onrestart.commands); // 初始化action结构的commands链表
list_add_tail(&service_list, &svc->slist); // 将当前服务添加到service_list链表中
return svc;
}
由上面分析可知，parse_service函数只是搭建了一个svc的框架，并最后把它链入了service_list链表。我们再来看看parse_line_service函数吧。
解析parse_line_service
static void parse_line_service(struct parse_state *state, int nargs, char **args)
{
struct service *svc = state->context;
struct command *cmd;
int i, kw, kw_nargs;
if (nargs == 0) {
return;
}
svc->ioprio_class = IoSchedClass_NONE;
kw = lookup_keyword(args[0]);
switch (kw) {
case K_capability:
break;
case K_class: // 用来修改classname
if (nargs != 2) {
parse_error(state, "class option requires a classname\n");
} else {
svc->classname = args[1];
}
break;
…
case K_oneshot:
svc->flags |= SVC_ONESHOT;
break;
case K_onrestart: // 开始解析onrestart后面的COMMAND
nargs--;
args++;
kw = lookup_keyword(args[0]);
if (!kw_is(kw, COMMAND)) {
parse_error(state, "invalid command '%s'\n", args[0]);
break;
}
kw_nargs = kw_nargs(kw);
if (nargs < kw_nargs) {
parse_error(state, "%s requires %d %s\n", args[0], kw_nargs - 1,
kw_nargs > 2 ? "arguments" : "argument");
break;
}
// 分配command结构的内存，拷贝参数等
cmd = malloc(sizeof(*cmd) + sizeof(char*) * nargs);
cmd->func = kw_func(kw);
cmd->nargs = nargs;
memcpy(cmd->args, args, sizeof(char*) * nargs);
// 添加到commands链表中
list_add_tail(&svc->onrestart.commands, &cmd->clist);
break;
…
case K_socket: {/* name type perm [ uid gid ] */
struct socketinfo *si;
if (nargs < 4) {
parse_error(state, "socket option requires name, type, perm arguments\n");
break;
}
if (strcmp(args[2],"dgram") && strcmp(args[2],"stream")
&& strcmp(args[2],"seqpacket")) {
parse_error(state, "socket type must be 'dgram', 'stream' or 'seqpacket'\n");
break;
}
si = calloc(1, sizeof(*si));
if (!si) {
parse_error(state, "out of memory\n");
break;
}
si->name = args[1]; // socket名字
si->type = args[2]; // socket类型
si->perm = strtoul(args[3], 0, 8); // socket读写权限
if (nargs > 4)
si->uid = decode_uid(args[4]);
if (nargs > 5)
si->gid = decode_uid(args[5]);
si->next = svc->sockets;
svc->sockets = si;
break;
}
…
default:
parse_error(state, "invalid option '%s'\n", args[0]);
}
}
parse_line_service函数将根据配置文件的内容填充service结构体，zygote service解析完之后的结果如下图所示：
解析完之后：
1. 全局的service_list链表将解析后的service全部链接到了一起。
2. socketinfo也是一个双向链表，这里链接了service用到的socket信息，zygote进程只有一个socket。
3. onrestart通过commands指向一个commands链表，zygote共有4个commands。
init控制service
启动zygote
init.rc的zygote服务中有这样一句话：
service zygote /system/bin/app_process-Xzygote /system/bin --zygote --start-system-server
class main
服务默认创建的时候classname为“default”，这里通过“class main”来修改classname为“main”。之后，我们再回过头去看init.rc中有这个一句话：
在init进程启动的boot阶段，有一句“class_start main”。而class_start是一个COMMAND，其对应的处理函数是do_class_start。接着来看看do_class_start函数吧：
int do_class_start(int nargs, char **args)
{
/*
Args为do_class_start的参数，init.rc中只有一个参数，就是“main“、“core”等。
service_for_each_class函数就是从service_list链表中找到classname和参数一致的service，
然后调用service_start_if_not_disabled函数。
*/
service_for_each_class(args[1], service_start_if_not_disabled);
return 0;
}
void service_for_each_class(const char *classname,
void (*func)(struct service *svc))
{
struct listnode *node;
struct service *svc;
list_for_each(node, &service_list) {
svc = node_to_item(node, struct service, slist);
if (!strcmp(svc->classname, classname)) {
func(svc);
}
}
}
service_start_if_not_disabled函数具体做了什么呢？接着看：
static void service_start_if_not_disabled(struct service *svc)
{
// 如果flags不为SVC_DISABLED，那么开始启动服务
if (!(svc->flags & SVC_DISABLED)) {
service_start(svc, NULL);
}
}
具体来看看服务的启动过程：
void service_start(struct service *svc, const char *dynamic_args)
{
struct stat s;
pid_t pid;
int needs_console;
int n;
char *scon = NULL;
int rc;
svc->flags &= (~(SVC_DISABLED|SVC_RESTARTING|SVC_RESET|SVC_RESTART));
svc->time_started = 0;
if (svc->flags & SVC_RUNNING) {
return;
}
needs_console = (svc->flags & SVC_CONSOLE) ? 1 : 0;
if (needs_console && (!have_console)) {
ERROR("service '%s' requires console\n", svc->name);
svc->flags |= SVC_DISABLED;
return;
}
/*
Service一般运行于另外一个进程中，这个进程也是init的子进程，所以启动service前需要判断对应的可执行文件是否存在，zygote服务对应的可执行文件为/system/bin/app_process
*/
if (stat(svc->args[0], &s) != 0) {
ERROR("cannot find '%s', disabling '%s'\n", svc->args[0], svc->name);
svc->flags |= SVC_DISABLED;
return;
}
if ((!(svc->flags & SVC_ONESHOT)) && dynamic_args) {
ERROR("service '%s' must be one-shot to use dynamic args, disabling\n",
svc->args[0]);
svc->flags |= SVC_DISABLED;
return;
}
// … 省略selinux相关的内容
// 通过fork创建一个子进程
pid = fork();
if (pid == 0) { // 在子进程中
struct socketinfo *si;
struct svcenvinfo *ei;
char tmp[32];
int fd, sz;
umask(077);
// 设置属性服务信息到环境变量
if (properties_inited()) {
get_property_workspace(&fd, &sz);
sprintf(tmp, "%d,%d", dup(fd), sz);
add_environment("ANDROID_PROPERTY_WORKSPACE", tmp);
}
// 设置属性进程的环境变量
for (ei = svc->envvars; ei; ei = ei->next)
add_environment(ei->name, ei->value);
setsockcreatecon(scon);
// 根据socketinfo创建socket，用于通信
for (si = svc->sockets; si; si = si->next) {
int socket_type = (
!strcmp(si->type, "stream") ? SOCK_STREAM :
(!strcmp(si->type, "dgram") ? SOCK_DGRAM : SOCK_SEQPACKET));
int s = create_socket(si->name, socket_type,
si->perm, si->uid, si->gid);
if (s >= 0) {
publish_socket(si->name, s);
}
}
….
if (!dynamic_args) {
/*
调用execve函数来执行/system/bin/app_process，这样就进入了app_process的main函数中了。
*/
if (execve(svc->args[0], (char**) svc->args, (char**) ENV) < 0) {
ERROR("cannot execve('%s'): %s\n", svc->args[0], strerror(errno));
}
} else {
…
}
_exit(127);
}
…
// 父进程中设置子服务进程的信息，启动时间、pid等。
svc->time_started = gettime();
svc->pid = pid;
svc->flags |= SVC_RUNNING;
// 如果属性服务已经初始化完毕了，那么就设置相应服务为running状态
if (properties_inited())
notify_service_state(svc->name, "running");
}
原来，zygote是通过fork和execv共同创建的，但是service结构中的onrestart字段好像没有派上用场，原因何在？我们接着往下看。
重启zygote
init进程在初始化的时候会调用signal_init函数来初始化一个socket对，主要用来父子进程间通信。
void signal_init(void)
{
int s[2];
struct sigaction act;
memset(&act, 0, sizeof(act));
/*
父进程设置sa_flags为SA_NOCLDSTOP，表明只有子进程在退出时父进程才能收到SIGCHLD的信号，处理函数为sigchld_handler
*/
act.sa_handler = sigchld_handler;
act.sa_flags = SA_NOCLDSTOP;
sigaction(SIGCHLD, &act, 0);
/* create a signalling mechanism for the sigchld handler */
if (socketpair(AF_UNIX, SOCK_STREAM, 0, s) == 0) {
signal_fd = s[0];
signal_recv_fd = s[1];
fcntl(s[0], F_SETFD, FD_CLOEXEC);
fcntl(s[0], F_SETFL, O_NONBLOCK);
fcntl(s[1], F_SETFD, FD_CLOEXEC);
fcntl(s[1], F_SETFL, O_NONBLOCK);
}
handle_signal();
}
因此，子进程在退出时，父进程收到SIGCHLD消息，此时，信号处理函数为sigchld_handler。
static void sigchld_handler(int s)
{
write(signal_fd, &s, 1);
}
signal_fd被写入值之后，那么对应的signal_recv_fd便能收到消息了。处理逻辑在init进程main函数的最后面的for循环中进行处理：
int get_signal_fd()
{
return signal_recv_fd;
}
for (i = 0; i < fd_count; i++) {
…
else if (ufds[i].fd == get_signal_fd())
handle_signal();
}
}
void handle_signal(void)
{
char tmp[32];
/* we got a SIGCHLD - reap and restart as needed */
read(signal_recv_fd, tmp, sizeof(tmp));
while (!wait_for_one_process(0))
;
}
static int wait_for_one_process(int block)
{
pid_t pid;
int status;
struct service *svc;
struct socketinfo *si;
time_t now;
struct listnode *node;
struct command *cmd;
// 获得退出进程的pid
while ( (pid = waitpid(-1, &status, block ? 0 : WNOHANG)) == -1 && errno == EINTR );
if (pid <= 0) return -1;
INFO("waitpid returned pid %d, status = %08x\n", pid, status);
// 遍历service_list链表，找到退出的那个服务
svc = service_find_by_pid(pid);
if (!svc) {
ERROR("untracked pid %d exited\n", pid);
return 0;
}
NOTICE("process '%s', pid %d exited\n", svc->name, pid);
/*
如果不是SVC_ONESHOT即一次性启动的服务，那么就杀死该进程的所有子进程，这也是为什么zygote死后，java世界崩溃的原因。
*/
if (!(svc->flags & SVC_ONESHOT) || (svc->flags & SVC_RESTART)) {
kill(-pid, SIGKILL);
NOTICE("process '%s' killing any children in process group\n", svc->name);
}
/* 删除服务创建的socket信息*/
for (si = svc->sockets; si; si = si->next) {
char tmp[128];
snprintf(tmp, sizeof(tmp), ANDROID_SOCKET_DIR"/%s", si->name);
unlink(tmp);
}
svc->pid = 0;
svc->flags &= (~SVC_RUNNING);
/*
如果服务进程的标志SVC_ONESHOT置位了，则表明此服务为一次性服务，死了之后就不需要重启，除非设置SVC_RESTART标志来手动重启该服务。
此类服务死了之后，就置为SVC_DISABLED
*/
if ((svc->flags & SVC_ONESHOT) && !(svc->flags & SVC_RESTART)) {
svc->flags |= SVC_DISABLED;
}
/* 通知属性服务器，将该服务属性设置为stopped */
if (svc->flags & (SVC_DISABLED | SVC_RESET) ) {
notify_service_state(svc->name, "stopped");
return 0;
}
now = gettime();
/*
如果进程带有SVC_CRITICA标志，那么此时如果进程在4分钟内，死了>4次，则重启进入到recovery模式。根据init.rc的配置可知，ueventd、healthd、servicemanager等服务享有此种特殊待遇。
*/
if ((svc->flags & SVC_CRITICAL) && !(svc->flags & SVC_RESTART)) {
if (svc->time_crashed + CRITICAL_CRASH_WINDOW >= now) {
if (++svc->nr_crashed > CRITICAL_CRASH_THRESHOLD) {
ERROR("critical process '%s' exited %d times in %d minutes; "
"rebooting into recovery mode\n", svc->name,
CRITICAL_CRASH_THRESHOLD, CRITICAL_CRASH_WINDOW / 60);
android_reboot(ANDROID_RB_RESTART2, 0, "recovery");
return 0;
}
} else {
svc->time_crashed = now;
svc->nr_crashed = 1;
}
}
svc->flags &= (~SVC_RESTART);
svc->flags |= SVC_RESTARTING;
/*
Execute all onrestart commands for this service.
Zygote将执行如下操作：
write /sys/android_power/request_state wake
write /sys/power/state on
restart media
restart netd
*/
list_for_each(node, &svc->onrestart.commands) {
cmd = node_to_item(node, struct command, clist);
cmd->func(cmd->nargs, cmd->args);
}
/* 重新通知属性服务器，将该服务属性设置为restarting */
notify_service_state(svc->name, "restarting");
return 0;
}
通过上面的代码可以知道onrestart的作用了，但是上述代码只是设置了相应svc的一些状态，flag、time_crashed、nr_crashed等等。那么真正的svc启动是在哪里呢？在init进程的main函数中，有一个大的无限循环，代码如下:
for(;;) {
int nr, i, timeout = -1;
execute_one_command();
// 此处就是调用service_start函数来重启那些flag带有SVC_RESTARTING的服务进程
restart_processes();
….
}
至此，死去的服务又开始重新启动了。