From 7f9522352ac04d73e752228e2c33b008d4a8fde0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=86=8A=E7=A3=8A?= Date: Tue, 1 Mar 2022 15:38:59 +0000 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0=E5=90=AF=E5=8A=A8=E5=BC=80?= =?UTF-8?q?=E5=8F=91=E6=8C=87=E5=8D=97=20Signed-off-by:=20xionglei=20?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../device-dev/subsystems/subsys-boot-init.md | 309 ++++++++++-------- 1 file changed, 172 insertions(+), 137 deletions(-) diff --git a/zh-cn/device-dev/subsystems/subsys-boot-init.md b/zh-cn/device-dev/subsystems/subsys-boot-init.md index 2c239f823a..74c194c86f 100755 --- a/zh-cn/device-dev/subsystems/subsys-boot-init.md +++ b/zh-cn/device-dev/subsystems/subsys-boot-init.md @@ -4,170 +4,165 @@ - [开发指导](#section15371931131117) - [开发实例](#section173413113565) -init启动引导组件负责在系统启动阶段启动关键服务进程。 若用户需要新增随开机自启动的系统服务，可将新增服务加入配置文件init.cfg中。 +init启动引导组件负责在系统启动阶段启动关键服务进程。 若用户需要新增随开机自启动的系统服务，可添加新的配置文件xxx.cfg，系统会自动分析对应的cfg文件，并按照cfg文件启动对应的服务。 ## init启动引导的配置文件 -init启动引导组件配置文件包含了所有需要由init进程启动的系统关键服务的服务名、可执行文件路径、权限和其他信息，该文件位于代码仓库“vendor/huawei/camera/init\_configs/“目录，烧写单板后可在“/etc/“目录下找到，文件名称为init.cfg，采用json格式，文件大小目前限制在100KB以内。 +init启动引导组件配置文件包含了所有需要由init进程启动的系统关键服务的服务名、可执行文件路径、权限和其他信息，烧写单板后可在“/etc/“目录下找到，文件名称为init.cfg，采用json格式，文件大小目前限制在100KB以内。 init进程启动后读取/etc/init.cfg，然后解析其json格式内容，并根据解析结果依次加载系统服务。 +各模块需要添加关键服务时，也可以添加模块对应的cfg文件，编译时拷贝文件到/system/etc/init目录下，init进程会解析改cfg文件，并启动对应的服务。 + +## init服务启动控制(仅标准系统以上提供) + +init会根据用户的服务配置，把服务分成三类，在不同的阶段进行启动。 + +- “boot”类型：对应系统中需要优先启动的服务，这类服务在init完成init阶段后启动。 +- “normal”类型：默认配置，对应系统中的普通服务，这类服务在init命令执行完成后启动。 +- "condition"类型：对应有特殊要求的服务，可以直接通过start xxx 命令执行启动，一般在条件job或者在init的某个阶段使用命令启动。 + +## init服务并行控制(仅标准系统以上提供) + +init提供服务并行处理能力，启动服务在不同的阶段执行job的能力。 + +- “on-start”：在服务进程被fock后执行，不同服务的on-start job可以并行执行（在服务的子进程中执行，只对改进程产生影响）。 +- “on-stop”：在服务停止时执行。 +- "on-restart"：在服务重启时执行。 + +## init 按需启动(仅标准系统以上提供) + +由init管理的服务支持按需启动，按需启动的服务不会在系统启动过程中主动被拉起，而是当某些事件发生时才会被init按需拉起，触发服务启动的事件可能是被init监听的相关socket有消息上报、samgr收到客户端的请求需要拉起SA服务等情况。 + +"ondemand" 属性是按需启动的服务的标志，一个服务配置了该属性值为true的时候，服务不再需要配置start命令来拉起，而是被监听的相应事件发生时才会被拉起。 + +* SA进程按需启动 +1. 应用请求SA句柄时samgr需识别SA所属进程是否可动态拉起 +2. 如需拉起，则需阻塞请求，等init拉起SA进程并注册SA后再返回所请求的SA句柄 + +* socket进程按需启动 +1. init在pre-fork阶段为socket类进程创建好socket，init中监听创建好的socket上的网络事件 +2. socket上有报文事件后，init拉起socket进程进行报文处理，init进程取消socket数据的监听，由socket进程处理 +3. socket进程无报文处理后，可以自动退出，退出后init回收该子进程并重新监听socket网络数据 + +* 热插拔服务进程按需启动 +ueventd的监听到热插拔事件后，可触发系统参数变化，业务进程可根据系统参数的变化进行热插拔事件按需启动处理。 + +## init 进程启动&回收能力增强 + +进程启动时，支持在配置文件中配置服务进程的绑核、优先级、MAC信息以及AccessToken信息。 +- init提供修改*.cfg配置文件， 为服务进程提供cpu绑核功能 +- init提供修改*.cfg配置文件， 为服务进程提供优先级设置 +- init提供修改*.cfg配置文件， 为服务提供设置AccessToken, 为系统服务进程设置其分布式Capability能力（仅标准系统以上提供）。 +- init提供修改*.cfg配置文件， 为服务提供抑制机制。 + +## init FD代持(仅标准系统以上提供) + +FD代持是按需启动的一个辅助扩展机制，按需启动进程可以保持退出前的fd状态句柄不丢失。按需启动进程退出前可将fd发送给init代持，再次启动后再从init获取fd。 + +init提供了相关接口供服务调用，服务进程退出前调用接口将fd通过支持IPC通信的socket发送给init代持，待该服务重新启动时，init将持有的该服务相关的fd句柄通过同样的方式返回给服务。 + +## init job + +init提供job能力，一个job就是一组命令的集合。job可以在init.cfg中配置，也可以在模块的自定义cfg中配置。init解析程序会把相同名字job的命令合并到一个job中。同一名字的job只能保证init.cfg中的命令优先执行，其他cfg间的命令执行顺序不保证。 + +- 普通job：一般是init启动的固定阶段，如“pre-init“，”init“，”post-init“等，这类job在init启动的固定阶段执行。 +- 自定义job：用户自定义的job，这类job按照一定的规则进行触发。 + - job：用户任意定义，可以通过trigger命令执行。 + - 控制job(仅标准系统以上提供)：按条件触发处理的能力。在job中可以设置触发条件，当对应的属性值满足设置的条件时，就会触发job执行。触发条件支持&&和||操作，可以根据不同的属性就行组合。 + ## 开发指导 1. 配置jobs数组。 - init启动引导组件将系统启动分为三个阶段： + init启动引导组件将系统启动分为三个阶段，这三个阶段： - “pre-init”阶段：启动系统服务之前需要先执行的操作，例如挂载文件系统、创建文件夹、修改权限等。 - “init”阶段：系统服务启动阶段。 - “post-init”阶段：系统服务启动完后还需要执行的操作。 - 上述每个阶段用一个job表示，一个job对应一个命令集合，init通过依次执行每个job中的命令来完成系统初始化。job执行顺序：先执行“pre-init”，再执行“init”，最后执行“post-init”。 - ``` - "jobs" : [{ - "name" : "pre-init", - "cmds" : [ - "mkdir /testdir", - "chmod 0700 /testdir", - "chown 99 99 /testdir", - "mkdir /testdir2", - "mount vfat /dev/mmcblk0p0 /testdir2 noexec nosuid" // mount命令，格式为：mount 文件系统类型 source target flags data - ] - }, { - "name" : "init", - "cmds" : [ - "start service1", - "start service2" - ] + "jobs" : [{ + "name" : "pre-init", + "cmds" : [ + "mkdir /testdir", + "chmod 0700 /testdir", + "chown 99 99 /testdir", + "mount vfat /dev/mmcblk0p0 /testdir2 noexec nosuid" // mount命令，格式为：mount 文件系统类型 source target flags data + ] + }, { + "name" : "init", + "cmds" : [ + "start service1", + ] }, { - "name" : "post-init", + "name" : "post-init", "cmds" : [] } - ], + ] ``` - **表 1** 执行job介绍 +表 1 执行job介绍 - - - - - - - - - - - - - - - -

job名

-

说明

-

pre-init

-

最先执行的job，如果开发者的进程在启动之前需要首先执行一些操作（例如创建文件夹），可以把操作放到pre-init中先执行。

-

init

-

中间执行的job，例如服务启动。

-

post-init

-

最后被执行的job，如果开发者的进程在启动完成之后需要有一些处理（如驱动初始化后再挂载设备），可以把这类操作放到该job执行。

-
+| job名 | 说明 | +| --------- | ------------------------------------------------------------ | +| pre-init | 最先执行的job，如果开发者的进程在启动之前需要首先执行一些操作（例如创建文件夹），可以把操作放到pre-init中先执行。 | +| init | 中间执行的job，例如服务启动。 | +| post-init | 最后被执行的job，如果开发者的进程在启动完成之后需要有一些处理（如驱动初始化后再挂载设备），可以把这类操作放到该job执行。 | - 单个job最多支持30条命令（当前仅支持start/mkdir/chmod/chown/mount/loadcfg），命令名称和后面的参数（参数长度≤128字节）之间有且只能有一个空格。 +表 2 命令集说明 - **表 2** 命令集说明 +| 命令 | 命令格式和示例 | 说明 | +| ------- | ------------------------------------------------------------ | ------------------------------------------------------------ | +| mkdir | mkdir 目标文件夹如：mkdir /storage/myDirectory | 创建文件夹命令，mkdir和目标文件夹之间有且只能有一个空格。 | +| chmod | chmod 权限 目标如：chmod 0600 /storage/myFile.txtchmod 0750 /storage/myDir | 修改权限命令，chmod权限目标之间间隔有且仅有一个空格，权限必须为0xxx格式。 | +| chown | chown uid gid 目标如：chown 900 800 /storage/myDirchown 100 100 /storage/myFile.txt | 修改属组命令，chown uid gid目标之间间隔有且仅有一个空格。 | +| mount | mount fileSystemType src dst flags data如：mount vfat /dev/mmcblk0 /sdc rw,umask=000mount jffs2 /dev/mtdblock3 /storage nosuid | 挂载命令，各参数之间有且仅有一个空格。flags当前仅支持nodev、noexec、nosuid、rdonly，data为可选字段。 | +| start | start serviceName如：start foundationstart shell | 启动服务命令，start后面跟着service名称，该service名称必须能够在services数组中找到。 | +| loadcfg | loadcfg filePath如：loadcfg /patch/fstab.cfg | 加载其他cfg文件命令。后面跟着的目标文件大小不得超过50KB，且目前仅支持加载/patch/fstab.cfg，其他文件路径和文件名均不支持。/patch/fstab.cfg文件的每一行都是一条命令，命令类型和格式必须符合本表格描述，命令条数不得超过20条。 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

命令

-

命令格式和示例

-

说明

-

mkdir

-

mkdir 目标文件夹

-

如：mkdir /storage/myDirectory

-

创建文件夹命令，mkdir和目标文件夹之间有且只能有一个空格。

-

chmod

-

chmod 权限 目标

-

如：chmod 0600 /storage/myFile.txt

-

chmod 0750 /storage/myDir

-

修改权限命令，chmod权限目标之间间隔有且仅有一个空格，权限必须为0xxx格式。

-

chown

-

chown uid gid 目标

-

如：chown 900 800 /storage/myDir

-

chown 100 100 /storage/myFile.txt

-

修改属组命令，chown uid gid目标之间间隔有且仅有一个空格。

-

mount

-

mount fileSystemType src dst flags data

-

如：mount vfat /dev/mmcblk0 /sdc rw,umask=000

-

mount jffs2 /dev/mtdblock3 /storage nosuid

-

挂载命令，各参数之间有且仅有一个空格。flags当前仅支持nodev、noexec、nosuid、rdonly，data为可选字段。

-

start

-

start serviceName

-

如：start foundation

-

start shell

-

启动服务命令，start后面跟着service名称，该service名称必须能够在services数组中找到。

-

loadcfg

-

loadcfg filePath

-

如：loadcfg /patch/fstab.cfg

-

加载其他cfg文件命令。后面跟着的目标文件大小不得超过50KB，且目前仅支持加载/patch/fstab.cfg，其他文件路径和文件名均不支持。/patch/fstab.cfg文件的每一行都是一条命令，命令类型和格式必须符合本表格描述，命令条数不得超过20条。

-
2. 配置services数组，service集合（数组形式），包含了init进程需要启动的所有系统服务（最多支持100个）。 ``` - "services" : [{ - "name" : "service1", - "path" : ["/bin/process1", "param1", "param2"], - "uid" : 1, - "gid" : 1, - "once" : 0, - "importance" : 1, - "caps" : [0, 1, 2, 5] - }, { - "name" : "service2", - "path" : "/bin/process2", - "uid" : 2, - "gid" : 2, - "once" : 1, - "importance" : 0, - "caps" : [ ] - } - ] + "services" : [{ + "name" : "service1", + "path" : ["/bin/process1", "param1", "param2"], + "uid" : 1, + "gid" : 1, + "once" : 0, + "importance" : 1, + "caps" : [0, 1, 2, 5], + "start-mode" : "condition", + "cpucore" : [0], + "critical" : [0, 5, 10], + "apl" : "normal", + "d-caps" : ["OHOS_DMS"] + "jobs" : { + "on-boot" : "boot", + "on-start" : "services:service1_start", + "on-stop" : "services:service1_stop", + "on-restart" : "services:service1_restart" + } + }, { + "name" : "service2", + "path" : "/bin/process2", + "uid" : 2, + "gid" : 2, + "once" : 1, + "importance" : 0, + "caps" : [ ]， + "cpucore" : 0, + "critical" : [ ], + "apl" : "normal", + "d-caps" : [ ] + }] ``` **表 3** service字段说明 + - + + + + + + + + + + + + + + + + + + + + + +

字段名

说明

@@ -204,9 +199,7 @@ init进程启动后读取/etc/init.cfg，然后解析其json格式内容，并

importance

当前服务进程是否为关键系统进程：

-

0：非关键系统进程，当该进程退出时，init不会将系统复位重启；

-

1：关键系统进程，当该进程退出时，init将系统复位重启。

+

当前服务进程优先级， 取值范围[19, -20]

caps

@@ -214,10 +207,45 @@ init进程启动后读取/etc/init.cfg，然后解析其json格式内容，并

当前服务所需的capability值，根据安全子系统已支持的capability，评估所需的capability，遵循最小权限原则配置（当前最多可配置100个值）。

critical

+

critical服务启动失败后， 需要M秒内重新拉起， 拉起失败N次后， 直接重启系统， N默认为4， M默认20。（仅标准系统以上提供 "critical" : [0, 2, 10]）

+

0：不使能；

+

1：使能。

+

cpucore

+

服务需要的绑定的cpu核心数， 类型为int型数组

+

d-caps

+

分布式能力 (仅标准系统以上提供)

+

apl

+

能力特权级别：system_core, normal, system_basic。 默认system_core (仅标准系统以上提供)

+

start-mode

+

服务的启动模式，具体描述：init服务启动控制(仅标准系统以上提供)

+

jobs

+

当前服务在不同阶段可以执行的job。具体说明可以看：init服务并行控制(仅标准系统以上提供)

+
- ## 开发实例 init启动引导程序，此处以要新增一个名为MySystemApp的系统服务为例进行说明，使用如下配置： @@ -248,7 +276,15 @@ init启动引导程序，此处以要新增一个名为MySystemApp的系统服 "gid" : 20, // MySystemApp系统服务的gid是20 "once" : 0, // MySystemApp系统服务的非一次性进程，即如果MySystemApp系统服务因任何原因退出，init进程需要将其重新拉起 "importance" : 0, // MySystemApp系统服务不是关键系统进程，即如果MySystemApp系统服务因任何原因退出，init进程无需重启单板 - "caps" : [] // MySystemApp系统服务不需要任何capability权限（即MySystemApp系统服务不涉及与capability相关的操作） + "caps" : [], // MySystemApp系统服务不需要任何capability权限（即MySystemApp系统服务不涉及与capability相关的操作） + "start-mode" : "condition", + "critical": [1, 2, 10], //MySystemApp系统服务的critical配置，需传入三个参数， 分别为使能：1， 执行次数：2， 执行时间：10 + "jobs" : { + "on-boot" : "boot", + "on-start" : "services:MySystemApp_start", + "on-stop" : "services:MySystemApp_stop", + "on-restart" : "services:MySystemApp_restart" + } } ] } @@ -258,5 +294,4 @@ init启动引导程序，此处以要新增一个名为MySystemApp的系统服 1. 启动后使用task -a（liteos-a版本）或ps命令（linux版本）查看是否MySystemApp系统服务进程已启动。 2. 使用kill命令将上述新增的MySystemApp进程杀死，观察该进程是否会被重新拉起（此处应该为重新拉起）。 -3. 使用kill命令将上述新增的MySystemApp进程杀死，观察是否会导致单板重启（此处应该为不重启）。 - +3. 使用kill命令将上述新增的MySystemApp进程杀死，观察是否会导致单板重启（此处应该为不重启）。 \ No newline at end of file -- GitLab