Android Framework分析（1）-init

分析基于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_done
    am.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_fd
    register_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_fd
    if (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_fd
    register_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

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 node
        int 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 pair
    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.
    //当捕获信号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来处理子进程是否退出的情况
    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中的数据，并放入buf
    read(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状态为restarting
    NotifyStateChange("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 ： 启动属于同一个class的所有服务；
start ： 启动指定的服务，若已启动则跳过；
stop ： 停止正在运行的服务
setprop ：设置属性值
mkdir ：创建指定目录
symlink ： 创建连接到的符号链接；
write ： 向文件path中写入字符串；
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-init
    trigger early-fs
    trigger fs
    trigger post-fs  
    trigger late-fs
    trigger post-fs-data
    trigger zygote-start
    trigger load_persist_props_action
    trigger firmware_mounts_complete
	trigger early-boot
    trigger boot

on post-fs
    # Load properties from
    #     /system/build.prop,
    #     /odm/build.prop,
    #     /vendor/build.prop and
    #     /factory/factory.prop
    load_system_props
    # start essential services
    start logd
    start servicemanager
    start hwservicemanager
    start vndservicemanager
   	mount rootfs rootfs / remount bind ro
    # Mount shared so changes propagate into child namespaces
    mount rootfs rootfs / shared rec
    # Mount default storage into root namespace
    mount none /mnt/runtime/default /storage bind rec
    mount 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 execute
    while (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最后一个命令，就从执行列表中移除action
    if (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()来回收僵尸子进程。