深入理解Android Framework(1)-init
总结
init进程(pid=1)是Linux系统中用户空间的第一个进程，主要工作如下：
1.创建一块共享的内存空间，用于属性服务器;
2.解析各个rc文件，并启动相应属性服务进程;
3.初始化epoll，依次设置signal、property、keychord这3个fd可读时相对应的回调函数;
进入无限循环状态，执行如下流程：
检查action_queue列表是否为空，若不为空则执行相应的action;
检查是否需要重启的进程，若有则将其重新启动;
4.进入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()来回收僵尸子进程。
源码分析
分析基于28的源码，涉及源码：
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()方法说起。
main
int main(int argc, char** argv) {//第一次挂载if (is_first_stage){......//挂载和创建一系列文件夹// Now that tmpfs is mounted on /dev and we have /dev/kmsg, we can actually// talk to the outside world...// 初始化Kernel日志InitKernelLogging(argv);LOG(INFO) << "init first stage started!";}// At this point we're in the second stage of init.InitKernelLogging(argv);LOG(INFO) << "init second stage started!";......//创建一块共享的内存空间，用于属性服务【见小节5.1】property_init();......//初始化epoll功能epoll_fd = epoll_create1(EPOLL_CLOEXEC);if (epoll_fd == -1) {PLOG(FATAL) << "epoll_create1 failed";}//初始化子进程退出的信号处理函数，并调用epoll_ctl设置signal fd可读的回调函数 sigchld_handler_init();//加载default.prop文件property_load_boot_defaults();//启动属性服务器，此处会调用epoll_ctl设置property fd可读的回调函数【见小节5.2】start_property_service(); ....... ActionManager& am = ActionManager::GetInstance();ServiceList& sm = ServiceList::GetInstance();//该方法内解析init.rc文件LoadBootScripts(am, sm);//one so we know ueventd has set up all of /dev...//执行rc文件中触发器为on early-init的语句am.QueueEventTrigger("early-init");//等冷插拔设备初始化完成am.QueueBuiltinAction(wait_for_coldboot_done_action, "wait_for_coldboot_done");// ... so that we can start queuing up actions that require stuff from /dev.am.QueueBuiltinAction(MixHwrngIntoLinuxRngAction, "MixHwrngIntoLinuxRng");am.QueueBuiltinAction(SetMmapRndBitsAction, "SetMmapRndBits");am.QueueBuiltinAction(SetKptrRestrictAction, "SetKptrRestrict");//设备组合键的初始化操作，此处会调用epoll_ctl设置keychord fd可读的回调函数am.QueueBuiltinAction(keychord_init_action, "keychord_init");// 屏幕上显示Android静态Logo 【见小节1.3】am.QueueBuiltinAction(console_init_action, "console_init");// Trigger all the boot actions to get us started.//执行rc文件中触发器为on init的语句am.QueueEventTrigger("init");// Repeat mix_hwrng_into_linux_rng in case /dev/hw_random or /dev/random// wasn't ready immediately after wait_for_coldboot_doneam.QueueBuiltinAction(MixHwrngIntoLinuxRngAction, "MixHwrngIntoLinuxRng");// Don't mount filesystems or start core system services in charger mode.//当处于充电模式，则charger加入执行队列；否则late-init加入队列。std::string bootmode = GetProperty("ro.bootmode", "");if (bootmode == "charger") {am.QueueEventTrigger("charger");} else {am.QueueEventTrigger("late-init");}// Run all property triggers based on current state of the properties.am.QueueBuiltinAction(queue_property_triggers_action, "queue_property_triggers");while (true) {// By default, sleep until something happens.int epoll_timeout_ms = -1;if (do_shutdown && !shutting_down) {do_shutdown = false;if (HandlePowerctlMessage(shutdown_command)) {shutting_down = true;}}if (!(waiting_for_prop || Service::is_exec_service_running())) {am.ExecuteOneCommand();}if (!(waiting_for_prop || Service::is_exec_service_running())) {if (!shutting_down) {//根据需要重启服务【见小节1.4】auto next_process_restart_time = RestartProcesses();// If there's a process that needs restarting, wake up in time for that.if (next_process_restart_time) {epoll_timeout_ms = std::chrono::ceil<std::chrono::milliseconds>(*next_process_restart_time - boot_clock::now()).count();if (epoll_timeout_ms < 0) epoll_timeout_ms = 0;}}// If there's more work to do, wake up again immediately.if (am.HasMoreCommands()) epoll_timeout_ms = 0;}epoll_event ev;//循环等待事件发生int nr = TEMP_FAILURE_RETRY(epoll_wait(epoll_fd, &ev, 1, epoll_timeout_ms));if (nr == -1) {PLOG(ERROR) << "epoll_wait failed";} else if (nr == 1) {((void (*)()) ev.data.ptr)();}}return 0;
}
看的LoadBootScripts方法内，逻辑就是去解析init.rc文件
static void LoadBootScripts(ActionManager& action_manager, ServiceList& service_list) {Parser parser = CreateParser(action_manager, service_list);std::string bootscript = GetProperty("ro.boot.init_rc", "");if (bootscript.empty()) {parser.ParseConfig("/init.rc");if (!parser.ParseConfig("/system/etc/init")) {late_import_paths.emplace_back("/system/etc/init");}if (!parser.ParseConfig("/product/etc/init")) {late_import_paths.emplace_back("/product/etc/init");}if (!parser.ParseConfig("/odm/etc/init")) {late_import_paths.emplace_back("/odm/etc/init");}if (!parser.ParseConfig("/vendor/etc/init")) {late_import_paths.emplace_back("/vendor/etc/init");}} else {parser.ParseConfig(bootscript);}
}
函数解释：
1.umask(0)
其实这个函数的作用，就是设置允许当前进程创建文件或者目录最大可操作的权限，比如这里设置为0，它的意思就是0取反再创建文件时权限相与，也就是：(~0) & mode 等于八进制的值0777 & mode了，这样就是给后面的代码调用函数mkdir给出最大的权限，避免了创建目录或文件的权限不确定性。
2.strcmp
strcmp() 用来比较字符串（区分大小写），其原型为：
int strcmp(const char *s1, const char *s2);
【返回值】若参数s1 和s2 字符串相同则返回0。s1 若大于s2 则返回大于0 的值。s1 若小于s2 则返回小于0 的值。
3.setenv
Linux setenv命令用于查询或显示环境变量。
4.mount
Linux mount命令是经常会使用到的命令，它用于挂载Linux系统外的文件。
5.mkdir
建立一个目录
6.emplace_back
emplace， 比如如果你想要向 std::vector 的末尾添加一个数据，你可以：
std::vector<int> nums;
nums.push_back(1)
你也可以使用：
std::vector<int> nums;
nums.empace_back(1);
emplace 最大的作用是避免产生不必要的临时变量
log.cpp
void InitKernelLogging(char* argv[]) {// Make stdin/stdout/stderr all point to /dev/null.int fd = open("/sys/fs/selinux/null", O_RDWR);if (fd == -1) {int saved_errno = errno;android::base::InitLogging(argv, &android::base::KernelLogger, InitAborter);errno = saved_errno;PLOG(FATAL) << "Couldn't open /sys/fs/selinux/null";}dup2(fd, 0);dup2(fd, 1);dup2(fd, 2);if (fd > 2) close(fd);android::base::InitLogging(argv, &android::base::KernelLogger, InitAborter);
}
上述代码将stdin、stdout、stderr全部重定向到/sys/fs/selinux/null(黑洞)中了，下面我们继续分析InitLogging函数
logging.cpp部分源码
void InitLogging(char* argv[], LogFunction&& logger, AbortFunction&& aborter) {SetLogger(std::forward<LogFunction>(logger));SetAborter(std::forward<AbortFunction>(aborter));......
}void SetLogger(LogFunction&& logger) {std::lock_guard<std::mutex> lock(LoggingLock());Logger() = std::move(logger);
}void SetAborter(AbortFunction&& aborter) {std::lock_guard<std::mutex> lock(LoggingLock());Aborter() = std::move(aborter);
}属性服务
现在我们来分析init进程很重要的一个功能属性服务
system/core/init/init.cpp
......
property_init();//初始化属性服务
......在Android系统中，所有的进程共享系统设置值，为此提供一个名称为属性的保存空间。init进程调用property_init函数，在共享内存区域中创建并初始化属性域。而后通过执行进程所提供的API访问属性域中的设置值。但更改属性域时，要预先向init进程提交值变更申请，然后init进程处理该申请，并修改属性值（用propert_set()和property_get()来处理）
......
epoll_fd = epoll_create1(EPOLL_CLOEXEC);//创建轮询的描述符
......
start_property_service();//开启属性服务
......epoll_create1用来创建轮询监听子进程终止和属性变更请求的文件描述符，后面会看到监听子进程终止套接字fd和属性变更请求套接字fd通过epoll_ctl注册到epoll_fd中，然后通过epoll_wait监听轮询这两个fd。
start_property_service()开启属性服务
void start_property_service() {......//创建用于接收属性变更请求的socket (/dev/socket/property_service)property_set_fd = CreateSocket(PROP_SERVICE_NAME, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,false, 0666, 0, 0, nullptr);......listen(property_set_fd, 8);//同时可以监听八个请求//注册property_set_fd到epoll_fdregister_epoll_handler(property_set_fd, handle_property_set_fd);
}如前所述，属性值的更改仅能在init进程中进行，即一个进程若想修改属性值，必须向init进程提交申请，为此init进程生成“/dev/socket/property_service”套接字，以接收其它进程提交的申请。
注册属性变更socket文件描述符（fd）到epoll_fd
system/core/init/init.cpp
void register_epoll_handler(int fd, void (*fn)()) {epoll_event ev;ev.events = EPOLLIN; //触发事件是当文件描述符可读时ev.data.ptr = reinterpret_cast<void*>(fn); //触发后的回调函数//注册属性socket fd到epoll_fdif (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, &ev) == -1) {PLOG(ERROR) << "epoll_ctl failed";}
}register_epoll_handler函数主要的作用是注册属性socket文件描述符到轮询描述符epoll_fd,当property_set_fd可读时，会调用上面register_epoll_handler函数的第二个参数(处理函数handle_property_set_fd())
system/core/init/property_service.cpp
static void handle_property_set_fd() {......uint32_t cmd = 0;if (!socket.RecvUint32(&cmd, &timeout_ms)) {//读取命令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;}......//设置属性值uint32_t result = HandlePropertySet(prop_name, prop_value,socket.source_context(), cr, &error);break;}case PROP_MSG_SETPROP2: ......当监听到属性变更时，从socket读取命令和属性名与属性值，设置新的属性或者更改属性值。HandlePropertySet最后会调用ActionManager::QueuePropetyChange将属性变更（属性触发器）添加到已触发队列中，最后会执行相应command命令(init.rc中定义的command)
处理子进程终止
现在我们来讲解init进程的另外一个重要功能，处理子进程终止。
system/core/init/init.cpp
......
sigchld_handler_init();//注册子进程死亡监听socket
......
system/core/init/sigchld_hanlder.cpp```c
void sigchld_handler_init() {// Create a signalling mechanism for SIGCHLD.int s[2];//创建套接字对，往一个socket中写，就可以从另外一个套接字中读取到数据if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK | SOCK_CLOEXEC, 0, s) == -1) {PLOG(FATAL) << "socketpair failed in sigchld_handler_init";}signal_write_fd = s[0];signal_read_fd = s[1];// Write to signal_write_fd if we catch SIGCHLD.struct sigaction act;memset(&act, 0, sizeof(act));act.sa_handler = SIGCHLD_handler;//收到SIGCHLD信号后的处理函数act.sa_flags = SA_NOCLDSTOP;sigaction(SIGCHLD, &act, 0);//注册SIGCHLD信号ReapAnyOutstandingChildren();//注册signal_read_fd到epoll_fdregister_epoll_handler(signal_read_fd, handle_signal);
}当init子进程意外终止时，会向init进程发送SIGCHLD信号，这个时候会调用SIGCHLD_handler这个处理函数。
system/core/init/sigchld_hanlder.cpp
static void SIGCHLD_handler(int) {if (TEMP_FAILURE_RETRY(write(signal_write_fd, "1", 1)) == -1) {PLOG(ERROR) << "write(signal_write_fd) failed";}
}SIGCHLD_handler的作用是当init进程接收到SIGCHLD信号时，往signal_write_fd中写入数据，这个时候套接字对中的另外一个signal_read_fd就可读了。
通过register_epoll_handler（这个函数上面已经分析过了）将signal_read_fd注册到epoll_fd中，当signal_read_fd可读时，会调用register_epoll_handler的第二个参数（handle_signal处理函数）。
handle_signal()函数分析
system/core/init/sigchld_hanlder.cpp
static void handle_signal() {// 清空signal_read_fd中的数据char buf[32];read(signal_read_fd, buf, sizeof(buf));ReapAnyOutstandingChildren();//见下
}void ReapAnyOutstandingChildren() {while (ReapOneProcess()) {//见下}
}static bool ReapOneProcess() {......//等待子进程终止auto reaper = make_scope_guard([pid] { TEMP_FAILURE_RETRY(waitpid(pid, nullptr, WNOHANG)); });......//获取到终止子进程对应的Service对象service = ServiceList::GetInstance().FindService(pid, &Service::pid);......//处理退出后的后续事项service->Reap(siginfo);......
}收到子进程的SIGCHLD信号后，找出该进程对应的Service对象，调用Reap函数。
service->Reap处理退出后进程的事项，如下：
system/core/init/service.cpp
void Service::Reap(const siginfo_t& siginfo) {//如果标志位是onshot或者是重启的子进程就杀掉整个进程组if (!(flags_ & SVC_ONESHOT) || (flags_ & SVC_RESTART)) {KillProcessGroup(SIGKILL);}// Oneshot processes go into the disabled state on exit,// except when manually restarted.if ((flags_ & SVC_ONESHOT) && !(flags_ & SVC_RESTART)) {flags_ |= SVC_DISABLED;}......//后续Init进程重启子进程会通过这个标志位来判断是否需要重启该子进程flags_ |= SVC_RESTARTING;......return;
}当init进程收到子进程意外终止SIGCHLD信号后，会根据对应进程Service对象的flags_标志位来判断该进程能不能重启，如果需要重启，就给flags_标志位添加SVC_RESTARTING标志位。
RestartProcesses
/system/core/init/init.cpp
static std::optional<boot_clock::time_point> RestartProcesses() {std::optional<boot_clock::time_point> next_process_restart_time;for (const auto& s : ServiceList::GetInstance()) {if (!(s->flags() & SVC_RESTARTING)) continue;auto restart_time = s->time_started() + 5s;if (boot_clock::now() > restart_time) {if (auto result = s->Start(); !result) {LOG(ERROR) << "Could not restart process '" << s->name() << "': " << result.error();}} else {if (!next_process_restart_time || restart_time < *next_process_restart_time) {next_process_restart_time = restart_time;}}}return next_process_restart_time;
}
检查service_list中的所有服务，对于带有SVC_RESTARTING标志的服务，则都会调用其相应的start()方法。
函数说明：
1.const auto&
当只想读取range中元素时，使用const auto&,如：for(const auto&x:range),它不会进行拷贝，也不会修改range
Result<Success> Service::Start() {bool disabled = (flags_ & (SVC_DISABLED | SVC_RESET));// Starting a service removes it from the disabled or reset state and// immediately takes it out of the restarting state if it was in there.flags_ &= (~(SVC_DISABLED|SVC_RESTARTING|SVC_RESET|SVC_RESTART|SVC_DISABLED_START));if (flags_ & SVC_RUNNING) {if ((flags_ & SVC_ONESHOT) && disabled) {flags_ |= SVC_RESTART;}// It is not an error to try to start a service that is already running.return Success();}bool needs_console = (flags_ & SVC_CONSOLE);if (needs_console) {if (console_.empty()) {console_ = default_console;}// Make sure that open call succeeds to ensure a console driver is// properly registered for the device nodeint console_fd = open(console_.c_str(), O_RDWR | O_CLOEXEC);if (console_fd < 0) {flags_ |= SVC_DISABLED;return ErrnoError() << "Couldn't open console '" << console_ << "'";}close(console_fd);}struct stat sb;if (stat(args_[0].c_str(), &sb) == -1) {flags_ |= SVC_DISABLED;return ErrnoError() << "Cannot find '" << args_[0] << "'";}........pid_t pid = -1;//如果该进程未启动，调用fork启动该进程if (namespace_flags_) {pid = clone(nullptr, nullptr, namespace_flags_ | SIGCHLD, nullptr);} else {pid = fork();}if (pid == 0) {umask(077);......}// priority. Aborts on failure.SetProcessAttributes();if (!ExpandArgsAndExecv(args_)) {PLOG(ERROR) << "cannot execve('" << args_[0] << "')";}_exit(127);}if (pid < 0) {pid_ = 0;return ErrnoError() << "Failed to fork";}.......time_started_ = boot_clock::now();pid_ = pid;flags_ |= SVC_RUNNING;start_order_ = next_start_order_++;process_cgroup_empty_ = false;.......NotifyStateChange("running");return Success();
}
其主要流程如下：
是否正在运行，如正在运行，直接返回；
子进程是否启动，如未启动，调用fork并返回pid值；
如果以上正常，则调用ExpandArgsAndExecve启动该进程，完成Zygote的启动。
信号处理
init.cpp的main()方法中通过signal_handler_init()来初始化信号处理过程。
主要工作：
初始化signal句柄；
循环处理子进程；
注册epoll句柄；
处理子进程的终止；
[-> signal_handler.cpp]
void sigchld_handler_init() {// Create a signalling mechanism for SIGCHLD.int s[2];// 创建socket pairif (socketpair(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK | SOCK_CLOEXEC, 0, s) == -1) {PLOG(FATAL) << "socketpair failed in sigchld_handler_init";}signal_write_fd = s[0];signal_read_fd = s[1];// Write to signal_write_fd if we catch SIGCHLD.//当捕获信号SIGCHLD，则写入signal_write_fdstruct 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来处理子进程是否退出的情况ReapAnyOutstandingChildren();//调用epoll_ctl方法来注册epoll的回调函数register_epoll_handler(signal_read_fd, handle_signal);
}
每个进程在处理其他进程发送的signal信号时都需要先注册，当进程的运行状态改变或终止时会产生某种signal信号，init进程是所有用户空间进程的父进程，当其子进程终止时产生SIGCHLD信号，init进程调用信号安装函数sigaction()，传递参数给sigaction结构体，便完成信号处理的过程。
这里有两个重要的函数：SIGCHLD_handler和handle_signal，如下：
sigchld_handler.cpp
//写入数据
static void SIGCHLD_handler(int) {//向signal_write_fd写入1，直到成功为止if (TEMP_FAILURE_RETRY(write(signal_write_fd, "1", 1)) == -1) {PLOG(ERROR) << "write(signal_write_fd) failed";}
}//读取数据
static void handle_signal() {// Clear outstanding requests.char buf[32];//读取signal_read_fd中的数据，并放入bufread(signal_read_fd, buf, sizeof(buf));ReapAnyOutstandingChildren();
}
ReapAnyOutstandingChildren()
void ReapAnyOutstandingChildren() {while (ReapOneProcess()) {}
}
ReapOneProcess
static bool ReapOneProcess() {siginfo_t siginfo = {};// This returns a zombie pid or informs us that there are no zombies left to be reaped.// It does NOT reap the pid; that is done below.//等待任意子进程，如果子进程没有退出则返回0，否则则返回该子进程pid。if (TEMP_FAILURE_RETRY(waitid(P_ALL, 0, &siginfo, WEXITED | WNOHANG | WNOWAIT)) != 0) {PLOG(ERROR) << "waitid failed";return false;}auto pid = siginfo.si_pid;if (pid == 0) return false;// At this point we know we have a zombie pid, so we use this scopeguard to reap the pid// whenever the function returns from this point forward.// We do NOT want to reap the zombie earlier as in Service::Reap(), we kill(-pid, ...) and we// want the pid to remain valid throughout that (and potentially future) usages.auto reaper = make_scope_guard([pid] { TEMP_FAILURE_RETRY(waitpid(pid, nullptr, WNOHANG)); });std::string name;std::string wait_string;Service* service = nullptr;if (PropertyChildReap(pid)) {name = "Async property child";} else if (SubcontextChildReap(pid)) {name = "Subcontext";} else {service = ServiceList::GetInstance().FindService(pid, &Service::pid);if (service) {name = StringPrintf("Service '%s' (pid %d)", service->name().c_str(), pid);if (service->flags() & SVC_EXEC) {auto exec_duration = boot_clock::now() - service->time_started();auto exec_duration_ms =std::chrono::duration_cast<std::chrono::milliseconds>(exec_duration).count();wait_string = StringPrintf(" waiting took %f seconds", exec_duration_ms / 1000.0f);}} else {name = StringPrintf("Untracked pid %d", pid);}}if (siginfo.si_code == CLD_EXITED) {LOG(INFO) << name << " exited with status " << siginfo.si_status << wait_string;} else {LOG(INFO) << name << " received signal " << siginfo.si_status << wait_string;}if (!service) return true;service->Reap(siginfo);if (service->flags() & SVC_TEMPORARY) {ServiceList::GetInstance().RemoveService(*service);}return true;
}
重点逻辑在service->Reap(siginfo)
service.cpp
void Service::Reap(const siginfo_t& siginfo) {//当flags为RESTART，且不是ONESHOT时，先kill进程组内所有的子进程或子线程if (!(flags_ & SVC_ONESHOT) || (flags_ & SVC_RESTART)) {KillProcessGroup(SIGKILL);}......// Oneshot processes go into the disabled state on exit,// except when manually restarted.//禁用和重置的服务，都不再自动重启if ((flags_ & SVC_ONESHOT) && !(flags_ & SVC_RESTART)) {flags_ |= SVC_DISABLED;}// Disabled and reset processes do not get restarted automatically.//禁用和重置的服务，都不再自动重启if (flags_ & (SVC_DISABLED | SVC_RESET)) {NotifyStateChange("stopped");return;}// If we crash > 4 times in 4 minutes, reboot into recovery.//服务在4分钟内重启次数超过4次，则重启手机进入recovery模式boot_clock::time_point now = boot_clock::now();if ((flags_ & SVC_CRITICAL) && !(flags_ & SVC_RESTART)) {if (now < time_crashed_ + 4min) {if (++crash_count_ > 4) {LOG(FATAL) << "critical process '" << name_ << "' exited 4 times in 4 minutes";}} else {time_crashed_ = now;crash_count_ = 1;}}flags_ &= (~SVC_RESTART);flags_ |= SVC_RESTARTING;// Execute all onrestart commands for this service.//执行当前service中所有onrestart命令onrestart_.ExecuteAllCommands();//设置相应的service状态为restartingNotifyStateChange("restarting");return;
}
另外：通过getprop | grep init.svc 可查看所有的service运行状态。状态总共分为：running, stopped, restarting
register_epoll_handler
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) {PLOG(ERROR) << "epoll_ctl failed";}
}
当fd可读，则会触发调用(*fn)函数。
rc文件语法
前面说了初始化init.rc,那么就得知道rc文件的语法
rc文件语法是以行尾单位，以空格间隔的语法，以#开始代表注释行。rc文件主要包含Action、Service、Command、Options，其中对于Action和Service的名称都是唯一的，对于重复的命名视为无效。
Action
Action： 通过触发器trigger，即以on开头的语句来决定执行相应的service的时机，具体有如下时机：
on early-init; 在初始化早期阶段触发；
on init; 在初始化阶段触发；
on late-init; 在初始化晚期阶段触发；
on boot/charger： 当系统启动/充电时触发，还包含其他情况，此处不一一列举；
on property:=: 当属性值满足条件时触发；
Service
服务Service，以 service开头，由init进程启动，一般运行在init的一个子进程，所以启动service前需要判断对应的可执行文件是否存在。init生成的子进程，定义在rc文件，其中每一个service在启动时会通过fork方式生成子进程。
例如： service servicemanager /system/bin/servicemanager代表的是服务名为servicemanager，服务执行的路径为/system/bin/servicemanager。
Command
下面列举常用的命令
class_start
start
stop
setprop ：设置属性值
mkdir
symlink
write
exec： fork并执行，会阻塞init进程直到程序完毕；
exprot ：设定环境变量；
loglevel ：设置log级别
Options
Options是Service的可选项，与service配合使用
disabled: 不随class自动启动，只有根据service名才启动；
oneshot: service退出后不再重启；
user/group： 设置执行服务的用户/用户组，默认都是root；
class：设置所属的类名，当所属类启动/退出时，服务也启动/停止，默认为default；
onrestart:当服务重启时执行相应命令；
socket: 创建名为/dev/socket/的socket
critical: 在规定时间内该service不断重启，则系统会重启并进入恢复模式
default: 意味着disabled=false，oneshot=false，critical=false。
init.rc文件的路径如下： /system/core/rootdir/init.rc
下面截取重要的代码段：
on early-init
on init
on late-inittrigger early-fstrigger fstrigger post-fs trigger late-fstrigger post-fs-datatrigger zygote-starttrigger load_persist_props_actiontrigger firmware_mounts_completetrigger early-boottrigger booton post-fs# Load properties from# /system/build.prop,# /odm/build.prop,# /vendor/build.prop and# /factory/factory.propload_system_props# start essential servicesstart logdstart servicemanagerstart hwservicemanagerstart vndservicemanagermount rootfs rootfs / remount bind ro# Mount shared so changes propagate into child namespacesmount rootfs rootfs / shared rec# Mount default storage into root namespacemount none /mnt/runtime/default /storage bind recmount none none /storage slave rec......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文件。
解析并执行init.rc文件
system/core/init/init.cpp
//am中的actions_成员变量用来保存action list(动作列表)
ActionManager& am = ActionManager::GetInstance();
//sm中的service_成员变量用来保存service list(服务列表)
ServiceList& sm = ServiceList::GetInstance();//解析rc文件，并将动作和服务分别添加到am和sm中
LoadBootScripts(am, sm);LoadBootScripts解析rc文件，将动作和服务添加到am的动作列表和sm的服务列表中去。
system/core/init/init.cpp
static void LoadBootScripts(ActionManager& action_manager, ServiceList& service_list) {//创建解析器Parser parser = CreateParser(action_manager, service_list);......//解析init.rc文件parser.ParseConfig("/init.rc");......
}Parser CreateParser(ActionManager& action_manager, ServiceList& service_list) {Parser parser;//添加ServiceParser触发器parser.AddSectionParser("service", std::make_unique<ServiceParser>(&service_list, subcontexts));//添加ActionParser触发器parser.AddSectionParser("on", std::make_unique<ActionParser>(&action_manager, subcontexts));//添加ImportParser触发器parser.AddSectionParser("import", std::make_unique<ImportParser>(&parser));return parser;
}void Parser::AddSectionParser(const std::string& name, std::unique_ptr<SectionParser> parser) {//以键值对的形式添加到section_parsers_中section_parsers_[name] = std::move(parser);
}分别将service(ServiceParser),on(ActionParser)和import(ImportParser)以键值对的形式添加到section_parsers_中。这三个Parser都继承自SectionParser,可以看到这里使用了组合和面向抽象编程的设计原则，将具体的解析器和解析行为解耦。下面会分析它们是如何使用相同的代码，不同的解析器解析不同的关键字（on,service,import等）。
现在分析ParseConfig(“/init.rc”)方法
system/core/init/parser.cpp
//ParseConfig->ParseConfigFile
bool Parser::ParseConfigFile(const std::string& path, size_t* parse_errors) {......//ReadFile将init.rc文件转换为config_contents字符串auto config_contents = ReadFile(path);......//解析config_contents字符串ParseData(path, *config_contents, parse_errors);......
}void Parser::ParseData(const std::string& filename, const std::string& data, size_t* parse_errors) {std::vector<char> data_copy(data.begin(), data.end());data_copy.push_back('\0');parse_state state;.......state.ptr = &data_copy[0];......std::vector<std::string> args;//lambda表达式，函数的引用，每次解析新的一行之前//都会调用这个将上一行解析的结果放到对应的数组中auto end_section = [&] {//⑤if (section_parser == nullptr) return;if (auto result = section_parser->EndSection(); !result) {(*parse_errors)++;LOG(ERROR) << filename << ": " << section_start_line << ": " << result.error();}//重置section_parser = nullptr;section_start_line = -1;};for (;;) {switch (next_token(&state)) { // ①case T_EOF:end_section();// ⑤ 上一行的解析工作return;case T_NEWLINE: // ⑦state.line++;......if (section_parsers_.count(args[0])) {//②end_section(); // ⑤ 上一行解析的收尾工作section_parser = section_parsers_[args[0]].get();section_start_line = state.line;auto result = section_parser->ParseSection(std::move(args), filename, state.line); // ③} else if (section_parser) {auto result = section_parser->ParseLineSection(std::move(args), state.line); // ④args.clear();break;case T_TEXT: // ⑥args.emplace_back(state.text);break;}}
}下面我们分析一下，ParseData是如何解析的：
①： next_token扫描init.rc中的token
找到其中的文件结束（EOF）、文本（TEXT）、新行（NEWLINE），其中的空格’ ‘、’\t’、’\r’会被忽略掉；对于TEXT,空格’ ‘、’\t’、’\r’、’\n’都是TEXT的结束标志。
例如：service ueventd /system/sbin/ueventd 中有三个TEXT (“servcie”、“ueventd”、“/system/sbin/”) 这些都会加入到args[]数组中⑥，然后就是⑦解析args数组
②： 会判断args[]第一个字符是不是on、service或import
如果是就拿到对应的解析器，例如是service开头的新行，section_parser就是对应之前添加的ServcieParser解析器，并且执行③，否则就执行④
③： 这里会执行ServiceParser解析器的ParseSection代码
会新建一个Service对象，变量名service_
④： 这里会执行ServiceParser解析器的ParseLineSection代码
这里是解析service下面附带的option(例如oneshot,class等等),并将这些属性添加到Service对象中)
小提示： 如果args[0]是"on",section_parser对应的就是ActionParser；如果是"import",section_parser对应的就是ImportParser；本文只会分析ServiceParser，另外两个解析器，读者可以参照着分析。
⑤： 解析完一个Service对象后
end_section()中的section_parser->EndSection()将Service对象添加到Service List（services_）中，并且重置section_parser = null，为解析下一个Service做准备。
system/core/init/service.cpp 分析③的代码：
Result<Success> ServiceParser::ParseSection(std::vector<std::string>&& args,const std::string& filename, int line) {const std::string& name = args[1];......std::vector<std::string> str_args(args.begin() + 2, args.end());//新建一个Service对象，args[1]表示服务名，后面的是运行参数service_ = std::make_unique<Service>(name, restart_action_subcontext, str_args);return Success();
}system/core/init/service.cpp 分析④的代码：
Result<Success> ServiceParser::ParseLineSection(std::vector<std::string>&& args, int line) {return service_ ? service_->ParseLine(std::move(args)) : Success();
}Result<Success> Service::ParseLine(const std::vector<std::string>& args) {static const OptionParserMap parser_map;//找到service中option对应的函数auto parser = parser_map.FindFunction(args);if (!parser) return parser.error();//执行相应的函数，添加对应的属性到Service对象中return std::invoke(*parser, this, args);
}下面我们看一下paser_map中option和函数名的对应关系。
system/core/init/service.cpp
static const Map option_parsers = {......{"class", {1, kMax, &Service::ParseClass}},{"console", {0, 1, &Service::ParseConsole}},{"disabled", {0, 0, &Service::ParseDisabled}},......{"oneshot", {0, 0, &Service::ParseOneshot}},{"onrestart", {1, kMax, &Service::ParseOnrestart}},......{"user", {1, 1, &Service::ParseUser}},};这个我们分析oneshot为例，oneshot对应的函数是Service::ParseOneshot。
Result<Success> Service::ParseOneshot(const std::vector<std::string>& args) {flags_ |= SVC_ONESHOT;return Success();
}std::invoke调用这个函数后，会将SVC_ONESHOT添加到这个Service对象中，当这个服务意外终止时，init进程会根据这个标志位而不去重启这个Service。
system/core/init/service.cpp 分析⑤的代码
Result<Success> ServiceParser::EndSection() {if (service_) {......//service_对象存在的时候，就添加到service list中service_list_->AddService(std::move(service_));}return Success();
}void ServiceList::AddService(std::unique_ptr<Service> service) {//将服务添加到Service List（services_）中services_.emplace_back(std::move(service));
}到这里一个服务就解析完成了，on和import依葫芦画瓢，可以自行分析。
on开头的使用ActionParser解析器解析,该解析器的ParseSection方法主要是生成action对象，并将action对象添加到actions_数组中，ParseLineSection方法主要是解析command对应的函数，然后添加到action对象的commands_数组中。细心的读者可能已经发现，ServiceParser的ParseLineSection是直接执行option对应函数,而ActionParser是将对应函数保存到commands_数组中，当Action触发时，才会依次执行command函数。
我们继续往下分析源码
system/core/init/init.cpp
// 解析init.rc文件，上面已经分析完
LoadBootScripts(am, sm);
......
// ① 触发early-init Action
am.QueueEventTrigger("early-init");// ② 新建一个"wait_for_coldboot_done"触发器，并且触发该触发器
am.QueueBuiltinAction(wait_for_coldboot_done_action, "wait_for_coldboot_done");
......
// ③ 触发"init"，触发器
am.QueueEventTrigger("init");①： 使用QueueEventTrigger方法触发early-init(还有一种触发方式是在rc文件中使用trigger命令，如trigger early-init)
system/core/init/action_manager.cpp
void ActionManager::QueueEventTrigger(const std::string& trigger) {event_queue_.emplace(trigger);
}event_queue_是一个保存以触发事件的队列,QueueEventTrigger(“early-init”)就表示触发了"early-init"事件
system/core/init/action_manager.h
std::queue<std::variant<EventTrigger, PropertyChange, BuiltinAction>> event_queue_;system/core/init/action.h
using EventTrigger = std::string;
using PropertyChange = std::pair<std::string, std::string>;
using BuiltinAction = class Action*;event_queue_可以存储三种触发器，EventTrigger(事件触发器，如on early-init)，PropertyChange(属性触发器,如on property: = )，例如：属性服务监听到属性变更请求时会添加该触发器，BuiltinAction(内建触发器,代码实时添加的，不在rc文件中配置)
②：创建内置触发器，并且触发
system/core/init/action_manager.cpp
void ActionManager::QueueBuiltinAction(BuiltinFunction func, const std::string& name) {//创建内置action对象auto action = std::make_unique<Action>(true, nullptr, "" , 0, name, std::map<std::string, std::string>{});std::vector<std::string> name_vector{name};//添加func到action对象的commands_数组中action->AddCommand(func, name_vector, 0);//触发内置触发器event_queue_.emplace(action.get());//添加action对象到action list（actions_数组中）actions_.emplace_back(std::move(action));
}③：触发事件触发器 on init
继续向下分析，就是依次执行已经触发的触发器action对象的command命令，并且监听属性服务和子进程的终止。
system/core/init/init.cpp
while (true) {......// ① am.ExecuteOneCommand();......// ②auto next_process_restart_time = RestartProcesses();......// ③int nr = TEMP_FAILURE_RETRY(epoll_wait(epoll_fd, &ev, 1, epoll_timeout_ms));}①：依次执行已触发aciton的command命令
system/core/init/action_manager.cpp
void ActionManager::ExecuteOneCommand() {// Loop through the event queue until we have an action to executewhile (current_executing_actions_.empty() && !event_queue_.empty()){for (const auto& action : actions_) {//如果该触发(event,就是前面说的三个触发器)匹配到当前action，就添加到current_excuting_actions_队列中if (std::visit([&action](const auto& event) { return action->CheckEvent(event); },event_queue_.front())) {current_executing_actions_.emplace(action.get());}}//从已触发事件弹出event_queue_.pop();}//如果没有可执行action，就直接返回if (current_executing_actions_.empty()) {return;}auto action = current_executing_actions_.front();......//每次执行一个命令action->ExecuteOneCommand(current_command_);// If this was the last command in the current action, then remove// the action from the executing list.++current_command_;//命令索引加一//如果是当前action最后一个命令，就从执行列表中移除actionif (current_command_ == action->NumCommands()) {current_executing_actions_.pop();current_command_ = 0;......}}
}从触发事件队列event_queue_中取出一个触发事件，从actions_中寻找匹配的action,然后添加到当前正在执行事件的队列current_executing_actions_中，取出aciton,依次执行action中commands_数组中的命令。遍历的执行上述操作，直至event_queue_和current_executing_actions_为空。
system/core/init/action.cpp
oid Action::ExecuteOneCommand(std::size_t command) const {Command cmd = commands_[command];//每次调用一个command命令ExecuteCommand(cmd);
}void Action::ExecuteCommand(const Command& command) const {......auto result = command.InvokeFunc(subcontext_);......
}②：重启需要重启的子进程
system/core/init/init.cpp
static std::optional<boot_clock::time_point> RestartProcesses() {......for (const auto& s : ServiceList::GetInstance()) {//如果是需要重启的服务，会添加SVC_RESTARTING标志位，前面已经介绍过if (!(s->flags() & SVC_RESTARTING)) continue;......//重启进程if (auto result = s->Start(); !result) {LOG(ERROR) << "Could not restart process '" << s->name() << "': " << result.error();}......
}③：上面通过epoll_ctl注册了属性服务和子进程终止，现在通过epoll_wait来真正的监听。当有属性申请和子进程终止时，就执行前面分析的对应的处理函数。
总结
init进程(pid=1)是Linux系统中用户空间的第一个进程，主要工作如下：
创建一块共享的内存空间，用于属性服务器;
解析各个rc文件，并启动相应属性服务进程;
初始化epoll，依次设置signal、property、keychord这3个fd可读时相对应的回调函数;
进入无限循环状态，执行如下流程：
检查action_queue列表是否为空，若不为空则执行相应的action;
检查是否需要重启的进程，若有则将其重新启动;
进入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()来回收僵尸子进程。
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！