Android系统启动-2-Init篇-1
基于 Android 6.0 的源码剖析, 分析Android启动过程进程号为1的init进程的工作内容。主要相关文件:
system/core/init/ - init.cpp - init_parser.cpp - signal_handler.cpp
一、概述
init 进程是 Linux 系统中用户空间的第一个进程,进程号固定为1。Kernel 启动后,在用户空间启动 init 进程,并调用 init 中的 main() 方法执行 init 进程的职责。对于 init 进程的功能分为4部分:
(1) 解析并运行所有的 init.rc 相关文件。
(2) 根据rc文件,生成相应的设备驱动节点。
(3) 处理子进程的终止(signal方式)。
(4) 提供属性服务的功能。
接下来从 main() 方法说起。
1.1 main
[-> init.cpp] static int epoll_fd = -1; int main(int argc, char** argv) { ... //设置文件属性0777 umask(0); //初始化内核log,位于节点/dev/kmsg【见小节1.2】 klog_init(); //设置输出的log级别 klog_set_level(KLOG_NOTICE_LEVEL); //创建一块共享的内存空间,用于属性服务【见小节5.1】 property_init(); //初始化epoll功能 epoll_fd = epoll_create1(EPOLL_CLOEXEC); //初始化子进程退出的信号处理函数,并调用epoll_ctl设置signal fd可读的回调函数【见小节2.1】 signal_handler_init(); //加载default.prop文件 property_load_boot_defaults(); //启动属性服务器,此处会调用epoll_ctl设置property fd可读的回调函数【见小节5.2】 start_property_service(); //解析init.rc文件 init_parse_config_file("/init.rc"); //执行rc文件中触发器为on early-init的语句 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"); //设备组合键的初始化操作,此处会调用epoll_ctl设置keychord fd可读的回调函数 queue_builtin_action(keychord_init_action, "keychord_init"); // 屏幕上显示Android静态Logo 【见小节1.3】 queue_builtin_action(console_init_action, "console_init"); //执行rc文件中触发器为on init的语句 action_for_each_trigger("init", action_add_queue_tail); queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng"); char bootmode[PROP_VALUE_MAX]; //当处于充电模式,则charger加入执行队列;否则late-init加入队列。 if (property_get("ro.bootmode", bootmode) > 0 && strcmp(bootmode, "charger") == 0) { action_for_each_trigger("charger", action_add_queue_tail); } else { action_for_each_trigger("late-init", action_add_queue_tail); } //触发器为属性是否设置 queue_builtin_action(queue_property_triggers_action, "queue_property_triggers"); while (true) { if (!waiting_for_exec) { execute_one_command(); //根据需要重启服务【见小节1.4】 restart_processes(); } int timeout = -1; if (process_needs_restart) { timeout = (process_needs_restart - gettime()) * 1000; if (timeout < 0) timeout = 0; } if (!action_queue_empty() || cur_action) { timeout = 0; } epoll_event ev; //循环等待事件发生 int nr = TEMP_FAILURE_RETRY(epoll_wait(epoll_fd, &ev, 1, timeout)); if (nr == -1) { ERROR("epoll_wait failed: %s\n", strerror(errno)); } else if (nr == 1) { ((void (*)()) ev.data.ptr)(); } } return 0; }
init 进程执行完成后进入循环等待 epoll_wait 的状态。
1.2 log系统
此时 android 的 log 系统还没有启动,采用 kernel 的 log 系统,打开的设备节点 /dev/kmsg, 那么可通过 cat /dev/kmsg 来获取内核 log。
接下来,设置 log 的输出级别为 KLOG_NOTICE_LEVEL(5),当 log 级别小于5时则会输出到 kernel log,默认值为3.
#define KLOG_ERROR_LEVEL 3 #define KLOG_WARNING_LEVEL 4 #define KLOG_NOTICE_LEVEL 5 #define KLOG_INFO_LEVEL 6 #define KLOG_DEBUG_LEVEL 7 #define KLOG_DEFAULT_LEVEL 3 //默认为3
1.3 console_init_action
[-> init.cpp] static int console_init_action(int nargs, char **args) { char console[PROP_VALUE_MAX]; if (property_get("ro.boot.console", console) > 0) { snprintf(console_name, sizeof(console_name), "/dev/%s", console); } int fd = open(console_name, O_RDWR | O_CLOEXEC); if (fd >= 0) have_console = 1; close(fd); fd = open("/dev/tty0", O_WRONLY | O_CLOEXEC); if (fd >= 0) { const char *msg; msg = "\n" "\n" "\n" "\n" "\n" "\n" "\n" // console is 40 cols x 30 lines,这里要显示在中间 "\n" "\n" "\n" "\n" "\n" "\n" "\n" " A N D R O I D "; write(fd, msg, strlen(msg)); close(fd); } return 0; }
这便是开机显示的底部带 ANDROID 字样的画面。
1.4 restart_processes
[-> init.cpp] static void restart_processes() { process_needs_restart = 0; service_for_each_flags(SVC_RESTARTING, restart_service_if_needed); }
检查 service_list 中的所有服务,对于带有 SVC_RESTARTING 标志的服务,则都会调用其相应的 restart_service_if_needed。
static void restart_service_if_needed(struct service *svc) { time_t next_start_time = svc->time_started + 5; if (next_start_time <= gettime()) { svc->flags &= (~SVC_RESTARTING); service_start(svc, NULL); return; } if ((next_start_time < process_needs_restart) || (process_needs_restart == 0)) { process_needs_restart = next_start_time; } }
之后再调用 service_start 来启动服务。
接下来,解读 init 的 main 方法中的4大块核心知识点:信号处理、rc文件语法、启动服务、属性服务。
二、信号处理
在小节[1.1]的 init.cpp 的 main() 方法中通过 signal_handler_init() 来初始化信号处理过程。
主要工作:
(1) 初始化signal句柄;
(2) 循环处理子进程;
(3) 注册epoll句柄;
(4) 处理子进程的终止;
2.1 signal_handler_init
[-> signal_handler.cpp] void signal_handler_init() { int s[2]; // 创建socket pair if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK | SOCK_CLOEXEC, 0, s) == -1) { exit(1); } signal_write_fd = s[0]; signal_read_fd = s[1]; //当捕获信号SIGCHLD,则写入signal_write_fd struct sigaction act; memset(&act, 0, sizeof(act)); act.sa_handler = SIGCHLD_handler; //SA_NOCLDSTOP 使init进程只有在其子进程终止时才会收到到 SIGCHLD 信号 act.sa_flags = SA_NOCLDSTOP; sigaction(SIGCHLD, &act, 0); //进入 waitpid来处理子进程是否退出的情况【见小节2.2】 reap_any_outstanding_children(); //调用 epoll_ctl 方法来注册epoll的回调函数【见小节2.3】 register_epoll_handler(signal_read_fd, handle_signal); }
每个进程在处理其他进程发送的 signal 信号时都需要先注册,当进程的运行状态改变或终止时会产生某种 signal 信号,init 进程是所有用户空间进程的父进程,当其子进程终止时产生 SIGCHLD 信号,init 进程调用信号安装函数 sigaction(),传递参数给 sigaction 结构体,便完成信号处理的过程。
这里有两个重要的函数:SIGCHLD_handler 和 handle_signal,如下:
//写入数据 static void SIGCHLD_handler(int) { //向 signal_write_fd 写入1,直到成功为止 if (TEMP_FAILURE_RETRY(write(signal_write_fd, "1", 1)) == -1) { ERROR("write(signal_write_fd) failed: %s\n", strerror(errno)); } } //读取数据 static void handle_signal() { char buf[32]; //读取 signal_read_fd 中的数据,并放入buf read(signal_read_fd, buf, sizeof(buf)); reap_any_outstanding_children(); 【见小节2.2】 }
2.2 reap_any_outstanding_children
[-> signal_handler.cpp] static void reap_any_outstanding_children() { while (wait_for_one_process()) { } } static bool wait_for_one_process() { int status; //等待任意子进程,如果子进程没有退出则返回0,否则则返回该子进程pid。 pid_t pid = TEMP_FAILURE_RETRY(waitpid(-1, &status, WNOHANG)); if (pid == 0) { return false; } else if (pid == -1) { return false; } //根据pid查找到相应的service service* svc = service_find_by_pid(pid); std::string name; if (!svc) { return true; } //当flags为RESTART,且不是ONESHOT时,先kill进程组内所有的子进程或子线程 if (!(svc->flags & SVC_ONESHOT) || (svc->flags & SVC_RESTART)) { kill(-pid, SIGKILL); } //移除当前服务svc中的所有创建过的socket for (socketinfo* si = svc->sockets; si; si = si->next) { char tmp[128]; snprintf(tmp, sizeof(tmp), ANDROID_SOCKET_DIR"/%s", si->name); unlink(tmp); } //当flags为EXEC时,释放相应的服务 if (svc->flags & SVC_EXEC) { waiting_for_exec = false; list_remove(&svc->slist); free(svc->name); free(svc); return true; } svc->pid = 0; svc->flags &= (~SVC_RUNNING); //对于ONESHOT服务,使其进入disabled状态 if ((svc->flags & SVC_ONESHOT) && !(svc->flags & SVC_RESTART)) { svc->flags |= SVC_DISABLED; } //禁用和重置的服务,都不再自动重启 if (svc->flags & (SVC_DISABLED | SVC_RESET)) { svc->NotifyStateChange("stopped"); //设置相应的service状态为stopped return true; } //服务在4分钟内重启次数超过4次,则重启手机进入recovery模式 time_t now = gettime(); if ((svc->flags & SVC_CRITICAL) && !(svc->flags & SVC_RESTART)) { if (svc->time_crashed + CRITICAL_CRASH_WINDOW >= now) { if (++svc->nr_crashed > CRITICAL_CRASH_THRESHOLD) { android_reboot(ANDROID_RB_RESTART2, 0, "recovery"); return true; } } else { svc->time_crashed = now; svc->nr_crashed = 1; } } svc->flags &= (~SVC_RESTART); svc->flags |= SVC_RESTARTING; //执行当前service中所有onrestart命令 struct listnode* node; list_for_each(node, &svc->onrestart.commands) { command* cmd = node_to_item(node, struct command, clist); cmd->func(cmd->nargs, cmd->args); } //设置相应的service状态为restarting svc->NotifyStateChange("restarting"); return true; }
另外:通过 getprop | grep init.svc 可查看所有的 service 运行状态。状态总共分为:running, stopped, restarting
2.3 register_epoll_handler
[-> signal_handler.cpp] void register_epoll_handler(int fd, void (*fn)()) { epoll_event ev; ev.events = EPOLLIN; ev.data.ptr = reinterpret_cast<void*>(fn); //将fd的可读事件加入到 epoll_fd 的监听队列中 if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, &ev) == -1) { ERROR("epoll_ctl failed: %s\n", strerror(errno)); } }
当fd上有可读事件,则会触发调用 (*fn) 函数。
三、rc文件语法
rc文件语法是以行为单位,以空格间隔的语法,以#开始代表注释行。rc文件主要包含 Action、Service、Command、Options,其中对于 Action 和 Service 的名称都是唯一的,对于重复的命名视为无效。#######
3.1 Action
Action:通过触发器 trigger,即以 on 开头的语句来决定执行相应的 service 的时机,具体有如下时机:
on early-init; 在初始化早期阶段触发; on init; 在初始化阶段触发; on late-init; 在初始化晚期阶段触发; on boot/charger: 当系统启动/充电时触发,还包含其他情况,此处不一一列举; on property:<key>=<value>: 当属性值满足条件时触发;
3.2 Service
服务Service,以 service 开头,由 init 进程启动,一般运行在 init 的一个子进程,所以启动 service 前需要判断对应的可执行文件是否存在。init 生成的子进程,定义在 rc 文件,其中每一个 service 在启动时会通过 fork 方式生成子进程。
例如:service servicemanager /system/bin/servicemanager 代表的是服务名为 servicemanager,服务执行文件的路径为 /system/bin/servicemanager。
3.3 Command
下面列举常用的命令:
class_start <service_class_name>:启动属于同一个 class 的所有服务; start <service_name>: 启动指定的服务,若已启动则跳过; stop <service_name>: 停止正在运行的服务 setprop <name> <value>:设置属性值 mkdir <path>:创建指定目录 symlink <target> <sym_link>: 创建连接到<target>的<sym_link>符号链接; write <path> <string>: 向文件path中写入字符串; exec: fork并执行,会阻塞init进程直到程序完毕; exprot <name> <name>:设定环境变量; loglevel <level>:设置log级别
3.4 Options
Options 是 Service 的可选项,与 service 命令配合使用
disabled: 不随 class 自动启动,只有根据 service 名才启动; oneshot: service 退出后不再重启; user/group:设置执行服务的用户/用户组,默认都是root; class:设置所属的类名,当所属类启动/退出时,服务也启动/停止,默认为 default; onrestart: 当服务重启时执行相应命令; socket: 创建名为 /dev/socket/<name> 的 socket critical: 在规定时间内该 service 不断重启,则系统会重启并进入恢复模式。 default: 意味着 disabled=false,oneshot=false,critical=false。
四、启动服务
4.1 启动顺序
on early-init on init on late-init trigger post-fs trigger load_system_props_action trigger post-fs-data trigger load_persist_props_action trigger firmware_mounts_complete trigger boot on post-fs //挂载文件系统 start logd mount rootfs rootfs / ro remount mount rootfs rootfs / shared rec mount none /mnt/runtime/default /storage slave bind rec ... on post-fs-data //挂载data start logd start vold //启动vold ... on boot //启动核心服务 ... class_start core //启动core class
触发器的执行顺序为 on early-init -> init -> late-init,从上面的代码可知,在 late-init 触发器中会触发文件系统挂载以及 on boot。在 on boot 过程会触发启动 core class。至于 main class 的启动是由 vold.decrypt 的以下4个值的设置所决定的, 该过程位于 system/vold/cryptfs.c 文件。
on nonencrypted class_start main class_start late_start on property:vold.decrypt=trigger_restart_min_framework class_start main on property:vold.decrypt=trigger_restart_framework class_start main class_start late_start on property:vold.decrypt=trigger_reset_main class_reset main on property:vold.decrypt=trigger_shutdown_framework class_reset late_start class_reset main
4.2 服务启动(Zygote)
在 init.zygote.rc 文件中,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
通过 init_parser.cpp 完成整个 service 解析工作,此处就不详细展开讲解析过程,该过程主要工作是:
(1) 创建一个名叫 ”zygote” 的 service 结构体;
(2) 创建一个用于 socket 通信的 socketinfo 结构体;
(3) 创建一个包含4个 onrestart 的 action 结构体。
Zygote 服务会随着 main class 的启动而启动,退出后会由 init 重启 zygote,即使多次重启也不会进入 recovery 模式。zygote 所对应的可执行文件是 /system/bin/app_process,通过调用 pid =fork() 创建子进程,通过 execve(svc->args[0], (char**)svc->args, (char**) ENV),进入 App_main.cpp 的 main() 函数。故 zygote 是通过 fork 和 execv 共同创建的。
流程如下:
而关于 Zygote 重启在前面的信号处理过程中讲过,是处理 SIGCHLD 信号,init 进程重启 zygote 进程,更多关于 Zygote 内容见之后的 Zygote 篇。
4.3 服务重启
当init子进程退出时,会产生SIGCHLD信号,并发送给init进程,通过socket套接字传递数据,调用到wait_for_one_process()方法,根据是否是oneshot,来决定是重启子进程,还是放弃启动。
所有的Service里面只有 servicemanager ,zygote ,surfaceflinger 这3个服务有onrestart关键字来触发其他service启动过程。
//zygote可触发media、netd重启 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 //servicemanager可触发healthd、zygote、media、surfaceflinger、drm重启 service servicemanager /system/bin/servicemanager class core user system group system critical onrestart restart healthd onrestart restart zygote onrestart restart media onrestart restart surfaceflinger onrestart restart drm //surfaceflinger可触发zygote重启 service surfaceflinger /system/bin/surfaceflinger class core user system group graphics drmrpc onrestart restart zygote
由上可知:
zygote:触发media、netd以及子进程(包括system_server进程)重启;
system_server: 触发zygote重启;
surfaceflinger:触发zygote重启;
servicemanager: 触发zygote、healthd、media、surfaceflinger、drm重启
所以,surfaceflinger,servicemanager,zygote自身以及system_server进程被杀都会触发Zygote重启。
五、属性服务
当某个进程A,通过 property_set() 修改属性值后,init 进程会检查访问权限,当权限满足要求后,则更改相应的属性值,属性值一旦改变则会触发相应的触发器(即rc文件中的on开头的语句),在 Android Shared Memmory(共享内存区域)中有一个 _system_property_area_ 区域,里面记录着所有的属性值。对于进程A通过 property_get() 方法,获取的也是该共享内存区域的属性值。
5.1 property_init
[-> property_service.cpp] void property_init() { //用于保证只初始化 _system_property_area_ 区域一次 if (property_area_initialized) { return; } property_area_initialized = true; //创建共享内存 if (__system_property_area_init()) { return; } pa_workspace.size = 0; pa_workspace.fd = open(PROP_FILENAME, O_RDONLY | O_NOFOLLOW | O_CLOEXEC); }
该方法核心功能在执行 __system_property_area_init() 方法,创建用于跨进程的共享内存。主要工作如下:
(1) 执行 open(),打开名为 ”/dev/properties“ 的共享内存文件,并设置大小为128KB;
(2) 执行 mmap(),将该内存映射到init进程;
(3) 将该内存的首地址保存在全局变量 __system_property_area__,后续的增加或者修改属性都基于该变量来计算位置。
关于加载的prop文件:
通过 load_all_load_all_propsprops()方法(应该是 load_system_props()),加载以下:
/system/build.prop; /vendor/build.prop; /factory/factory.prop; /data/local.prop; /data/property路径下的persist属性
5.2 start_property_service
[-> property_service.cpp] void start_property_service() { property_set("ro.property_service.version", "2"); property_set_fd = CreateSocket(PROP_SERVICE_NAME, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK, false, 0666, 0, 0, nullptr, sehandle); listen(property_set_fd, 8); //设置 property 文件描述符可读的回调函数【见小节2.3】 register_epoll_handler(property_set_fd, handle_property_set_fd); }
创建并监听名叫 “property_service” 的 socket,再利用 epoll_ctl 设置 property 文件描述符触发可读时的回调函数为 handle_property_set_fd,接下来看看该函数的实现。
5.3 handle_property_set_fd
static void handle_property_set_fd() { static constexpr uint32_t kDefaultSocketTimeout = 2000; /* ms */ int s = accept4(property_set_fd, nullptr, nullptr, SOCK_CLOEXEC); struct ucred cr; socklen_t cr_size = sizeof(cr); getsockopt(s, SOL_SOCKET, SO_PEERCRED, &cr, &cr_size) < 0); SocketConnection socket(s, cr); uint32_t timeout_ms = kDefaultSocketTimeout; //设置2秒超时 uint32_t cmd = 0; if (!socket.RecvUint32(&cmd, &timeout_ms)) { socket.SendUint32(PROP_ERROR_READ_CMD); return; } switch (cmd) { case PROP_MSG_SETPROP: { char prop_name[PROP_NAME_MAX]; char prop_value[PROP_VALUE_MAX]; if (!socket.RecvChars(prop_name, PROP_NAME_MAX, &timeout_ms) || !socket.RecvChars(prop_value, PROP_VALUE_MAX, &timeout_ms)) { return; } prop_name[PROP_NAME_MAX-1] = 0; prop_value[PROP_VALUE_MAX-1] = 0; //设置property【见小节5.4】 handle_property_set(socket, prop_value, prop_value, true); break; } case PROP_MSG_SETPROP2: { std::string name; std::string value; if (!socket.RecvString(&name, &timeout_ms) || !socket.RecvString(&value, &timeout_ms)) { socket.SendUint32(PROP_ERROR_READ_DATA); return; } //设置property【见小节5.4】 handle_property_set(socket, name, value, false); break; } default: socket.SendUint32(PROP_ERROR_INVALID_CMD); break; } }
这里针对socket接收事件设置2秒超时,也就是说 property 的设置过程有可能耗时。
5.4 handle_property_set
static void handle_property_set(SocketConnection& socket, const std::string& name, const std::string& value, bool legacy_protocol) { const char* cmd_name = legacy_protocol ? "PROP_MSG_SETPROP" : "PROP_MSG_SETPROP2"; if (!is_legal_property_name(name)) { //检查属性名是否合规 socket.SendUint32(PROP_ERROR_INVALID_NAME); return; } struct ucred cr = socket.cred(); char* source_ctx = nullptr; getpeercon(socket.socket(), &source_ctx); if (android::base::StartsWith(name, "ctl.")) { if (check_control_mac_perms(value.c_str(), source_ctx, &cr)) { //处理以ctl.开头的属性 handle_control_message(name.c_str() + 4, value.c_str()); } ... } else { if (check_perms(name, source_ctx, &cr)) { //设置属性名和属性值 uint32_t result = property_set(name, value); } ... } freecon(source_ctx); }
这里会检测属性名是否合规,具体检查规范如下:
bool is_legal_property_name(const std::string& name) { size_t namelen = name.size(); if (namelen < 1) return false; if (name[0] == '.') return false; if (name[namelen - 1] == '.') return false; /* Only allow alphanumeric, plus '.', '-', '@', ':', or '_' */ /* Don't allow ".." to appear in a property name */ for (size_t i = 0; i < namelen; i++) { if (name[i] == '.') { // i=0 is guaranteed to never have a dot. See above. if (name[i-1] == '.') return false; continue; } if (name[i] == '_' || name[i] == '-' || name[i] == '@' || name[i] == ':') continue; if (name[i] >= 'a' && name[i] <= 'z') continue; if (name[i] >= 'A' && name[i] <= 'Z') continue; if (name[i] >= '0' && name[i] <= '9') continue; return false; } return true; } uint32_t property_set(const std::string& name, const std::string& value) { return PropertySetImpl(name, value); } static uint32_t PropertySetImpl(const std::string& name, const std::string& value) { size_t valuelen = value.size(); if (!is_legal_property_name(name)) { return PROP_ERROR_INVALID_NAME; } if (valuelen >= PROP_VALUE_MAX) { //属性名不可过长 return PROP_ERROR_INVALID_VALUE; } prop_info* pi = (prop_info*) __system_property_find(name.c_str()); if (pi != nullptr) { // 以ro.开头的属性不可更改 if (android::base::StartsWith(name, "ro.") && strcmp(name.c_str(),"ro.build.software.version")) { return PROP_ERROR_READ_ONLY_PROPERTY; } //更新属性 __system_property_update(pi, value.c_str(), valuelen); } else { //添加属性 int rc = __system_property_add(name.c_str(), name.size(), value.c_str(), valuelen); } //以persist.开头的属性需要持久化 if (persistent_properties_loaded && android::base::StartsWith(name, "persist.")) { write_persistent_property(name.c_str(), value.c_str()); } //属性值改变的通知过程 ######### property_changed(name, value); return PROP_SUCCESS; }
不同属性执行逻辑有所不同,主要区分如下:
(1) 属性名以 ctl. 开头,则表示是控制消息,控制消息用来执行一些命令。例如:
setprop ctl.start bootanim 查看开机动画;
setprop ctl.stop bootanim 关闭开机动画;
setprop ctl.start pre-recovey 进入 recovery 模式;
(2) 属性名以 ro. 开头,则表示是只读的,不能设置,所以直接返回;
(3) 属性名以 persist. 开头,则需要把这些值写到对应文件;需要注意的是,persist 用于持久化保存某些属性值,当同时也带来了额外的IO操作。
六、总结
6.1 init 进程(pid=1)是Linux系统中用户空间的第一个进程,主要工作如下:
(1) 创建一块共享的内存空间,用于属性服务器;
(2) 解析各个rc文件,并启动相应属性服务进程;
(3) 初始化epoll,依次设置 signal、property、keychord 这3个fd可读时相对应的回调函数;
(4) 进入无限循环状态,执行如下流程:
a. 检查 action_queue 列表是否为空,若不为空则执行相应的 action;
b. 检查是否需要重启的进程,若有则将其重新启动;
c. 进入 epoll_wait 等待状态,直到系统属性变化事件(property_set()改变属性值),或者收到子进程的信号 SIGCHLD,再或者 keychord 键盘输入事件,则会退出等待状态,执行相应的回调函数。
可见 init 进程在开机之后的核心工作就是响应 property 变化事件和回收僵尸进程。当某个进程调用 property_set() 来改变一个系统属性值时,系统会通过 socket 向 init 进程发送一个 property 变化的事件通知,那么 property fd 会变成可读,init 进程采用 epoll 机制监听该 fd 则会触发回调 handle_property_set_fd()方法。回收僵尸进程,在Linux内核中,如父进程不等待子进程的结束直接退出,会导致子进程在结束后变成僵尸进程,占用系统资源。为此,init 进程专门安装了 SIGCHLD 信号接收器,当某些子进程退出时发现其父进程已经退出,则会向 init 进程发送 SIGCHLD 信号,init 进程调用回调方法 handle_signal() 来回收僵尸子进程。
参考:
http://gityuan.com/2016/02/05/android-init/
posted on 2023-05-07 15:43 Hello-World3 阅读(163) 评论(0) 编辑 收藏 举报