Skip to content

D
Docs

OpenHarmony / Docs
大约 2 年 前同步成功

通知 161
Star 293
Fork 28
D
Docs
You need to sign in or sign up before continuing.
提交 fc90db48 编写于 作者: L laiguizhong
浏览文件
操作

修改init开发指南 

Signed-off-by: Nlaiguizhong <laiguizhong@huawei.com>
上级 4f3a4d0c
显示空白变更内容
内联 并排
Showing with 1092 addition and 550 deletion
zh-cn/device-dev/subsystems/subsys-boot-init-cfg.md 0 → 100644
浏览文件 @ fc90db48
# 引导启动配置文件
## 概述
### 功能简介
Init配置文件基于JSON格式，用来配置系统启动时必要的命令和服务。Init在系统启动时解析配置文件，并根据配置文件执行对应的命令，启动相应的服务。
### 基本概念
1. 分组配置文件（device.xxxx.group.cfg）（标准系统支持），文件由jobs、services和groups组成。用来限制能够执行的jobs和service。根据cmdline中的bootgroup属性决定当前的分区。当前支持下列分组：
- ​device.boot.group 系统默认配置，触发执行配置文件中的所有的job和服务。
- device.charge.group charge模式，限制只启动改文件中允许的job和服务。
2. 启动配置文件（init.cfg），文件由jobs、services和import组成。
- services（linux内核支持）， 用于配置系统支持的native服务，服务具体配置参考 **[服务管理](subsys-boot-init-service.md)**。
- jobs， 配置等待执行命令集合，jobs具体参考 **[jobs管理](subsys-boot-init-jobs.md)**。
- import（linux内核支持），import是导入cfg文件，目的是减少cfg大小，分离不同的功能。
### 约束与限制
仅支持小型系统和标准系统。
## 开发指导
### 场景介绍
init进程启动时，首先完成系统初始化工作，然后开始解析配置文件。系统在解析配置文件时，会将配置文件分成三类：
1. init.cfg默认配置文件，由init系统定义，优先解析。
2. /system/etc/init/*.cfg各子系统定义的配置文件。
3. /vendor/etc/init/*.cfg厂商定义的配置文件。
当需要添加配置文件时，用户可以根据需要定义自己的配置文件，并拷贝到相应的目录下。
### 开发步骤
1. 定义配置文件。
```
{
"import" : [ ],
"jobs" : [ ],
"services" : [ ]
}
```
2. 根据具体的系统拷贝配置到相应的目录。
标准系统下：
```
ohos_prebuilt_etc("misc.cfg") {
source = "//base/startup/init_lite/services/etc/misc.cfg"
relative_install_dir = "init"
part_name = "init"
}
```
小型系统下：
```
copy("init_configs") {
sources = [ "init_liteos_a_3516dv300.cfg" ]
outputs = [ "$root_out_dir/config/init.cfg" ]
}
```
### 开发实例
下述为cfg文件编写模板。
```
{
"import" : [
"/etc/example1.cfg",
"/etc/example2.cfg"
],
"jobs" : [{
"name" : "jobName1",
"cmds" : [
"start serviceName",
"mkdir dir1"
]
}, {
"name" : "jobName2",
"cmds" : [
"chmod 0755 dir1",
"chown root root dir1"
]
}
],
"services" : [{
"name" : "serviceName",
"path" : ["/system/bin/serviceName"]
}
]
}
```
1. cfg文件是严格按照JSON格式编写的，当添加服务或命令未生效时，可以优先排查添加内容的格式是否正确。
2. 对于import解析，在解析完成一个import中的cfg文件路径时，会立即解析该cfg文件。
3. example1.cfg 需要导入的cfg文件。
4. serviceName：service名称， 用户自定义。
5. /system/bin/serviceName: 当前服务的可执行文件全路径和参数， 数组形式。
6. jobName1：job名称， 用户自定义。
zh-cn/device-dev/subsystems/subsys-boot-init-jobs.md 0 → 100644
浏览文件 @ fc90db48
# jobs管理
## 概述
### 功能简介
jobs是init组件下cfg文件中的一组命令构成的集合, 最多添加4096个job。 jobs可以在 **[cfg](subsys-boot-init-cfg.md)** 文件中配置，通常在init启动过程中执行，服务于service的正常启动或特定基础功能的初始化。
### 基本概念
job可以在init.cfg中配置，也可以在模块的自定义cfg中配置。init解析程序会把相同名字job的命令合并到一个job中。同一名字的job只能保证init.cfg中的命令优先执行，其他cfg间的命令执行顺序不保证。
- 基本jobs
init启动的固定阶段，如“pre-init“，“init”，“post-init”，这类job在init启动的固定阶段执行。
- pre-init：init前置阶段，其他服务所依赖的，类似于ueventd、watchdog、hilogd等的关键服务会在这一阶段启动，data分区的挂载也在这一阶段进行。
- init：init进程的主要阶段，这一阶段除了大量命令的执行，同时也是init分组并行启动boot组（第一组）服务的启动阶段，一些关乎系统功能的重要服务会在这一阶段被拉起。
- post-init：这一阶段主要是通过trigger命令触发其他阶段执行，可以把所有被触发的阶段看作一个个的小阶段，也可以把它们统一看作post-init阶段，这一阶段会执行大量命令，并且它还是init分组并行启动normal组（第二组）服务的启动阶段，cfg中配置的大部分服务都是在这一阶段被拉起的。
- 自定义jobs(仅标准系统以上提供)
这类job按照一定的规则进行触发，用户根据需要定义的命令集合，通过trigger命令触发执行。
- 条件jobs(仅标准系统以上提供)
用户通过在jobs中添加condition条件，在条件触发时执行。
条件一般是某些系统参数值的组合，支持&& 、||等操作，例如"condition"："sys.usb.config = none && sys.usb.configfs = 0"。并且jobs在定义命令时，一般按照下面的规则"param:xxx", 可以根据不同的属性自行组合。
### 约束与限制
在标准系统下有系统参数模块的支持，支持基本jobs、条件jobs、自定义jobs。在小型系统中只支持基本jobs。
## 开发指导
### 场景介绍
job就是命令集合，jobs管理就是对要执行的一组命令集合进行管理， 一组命令集合最多添加4096个命令。在init启动过程中，jobs的执行为服务的正常运行提供支持。
### 参数说明
**表1** 命令集说明
| 命令 | 命令格式和示例 | 说明 | 支持系统类型 |
| -------- | -------- | -------- | -------- |
| mkdir | mkdir&nbsp;目标文件夹<br/>如：mkdir&nbsp;/storage/myDirectory | 创建文件夹命令，mkdir和目标文件夹之间有且只能有一个空格。 | 小型系统和标准系统 |
| chmod | chmod&nbsp;权限&nbsp;目标<br/>如：chmod&nbsp;0600&nbsp;/storage/myFile.txt<br/>chmod&nbsp;0750&nbsp;/storage/myDir | 修改权限命令，chmod权限目标之间间隔有且仅有一个空格，权限必须为0xxx格式。 | 小型系统和标准系统|
| chown | chown&nbsp;uid&nbsp;gid&nbsp;目标<br/>如：chown&nbsp;900&nbsp;800&nbsp;/storage/myDir<br/>chown&nbsp;100&nbsp;100&nbsp;/storage/myFile.txt | 修改属组命令，chown&nbsp;uid&nbsp;gid目标之间间隔有且仅有一个空格。 | 小型系统和标准系统 |
| mount | mount&nbsp;fileSystemType&nbsp;src&nbsp;dst&nbsp;flags&nbsp;data<br/>如：mount&nbsp;vfat&nbsp;/dev/mmcblk0&nbsp;/sdc&nbsp;rw,umask=000<br/>mount&nbsp;jffs2&nbsp;/dev/mtdblock3&nbsp;/storage&nbsp;nosuid | 挂载命令，各参数之间有且仅有一个空格。flags当前仅支持nodev、noexec、nosuid、rdonly，data为可选字段。 | 小型系统和标准系统 |
| start | start&nbsp;serviceName<br/>如：start&nbsp;foundation<br/>start&nbsp;shell | 启动服务命令，start后面跟着service名称，该service名称必须能够在services数组中找到。 | 小型系统和标准系统 |
| export | export key value<br>如：export TEST /data/test | 设置环境变量命令。后面跟两个参数，第一个参数是环境变量名，第二个参数是环境变量值。| 小型系统和标准系统 |
| rm | rm filename<br>如：rm /data/testfile | 删除文件命令。后面跟一个参数，即文件的绝对路径。 | 小型系统和标准系统 |
| rmdir | rmdir dirname<br>如：rmdir /data/testdir | 删除目录命令。后面跟一个参数，即目录的绝对路径。 | 小型系统和标准系统 |
| write | write filename value<br>如：write /data/testfile 0 | 写文件命令。后面跟两个参数，第一个参数是文件的绝对路径，第二个参数是要写入文件的字符串。 | 小型系统和标准系统 |
| stop | stop servicename<br>如：stop console | 关闭服务命令。后面跟一个参数，即要关闭的服务名。 | 小型系统和标准系统 |
| copy | copy oldfile newfile<br>如：copy /data/old /data/new | 拷贝文件命令。后面跟两个参数，第一个参数是原文件绝对路径，第二个参数是新文件绝对路径。 | 小型系统和标准系统 |
| reset | reset servicename<br>如：reset console | 重启服务命令。后面跟一个参数，即要重启的服务名。目前reset命令的策略是，如果一个服务没有启动，则该命令会将其拉起，如果一个服务处于运行状态，则该命令会将其关闭后重启。| 小型系统和标准系统 |
| reboot | reboot (subsystem)<br>如：reboot updater | 重启系统命令。后面可以跟一个参数，也可以没有参数，当没有参数时执行该命令，将会使设备重启到当前系统，当后面跟参数时，参数应当是子系统的名字，例如,reboot updater，将会重启进入updater子系统。 | 小型系统和标准系统 |
| sleep | sleep time<br>如：sleep 5 | 睡眠命令。后面可以跟一个参数，该参数是睡眠时间。 | 小型系统和标准系统 |
| domainname | domainname name<br>如：domainname localdomain | 设置域名。 | 小型系统和标准系统 |
| hostname | hostname name<br>如：hostname localhost | 设置主机名命令。 | 小型系统和标准系统 |
| wait | wait PID<br>如：wait pid | 等待命令。| 小型系统和标准系统 |
| setrlimit | setrlimit resource curValue maxValue<br>如：| 设定资源使用限制命令。 | 小型系统和标准系统 |
| write | write path content<br>如：write /proc/sys/kernel/sysrq 0 | 写文件命令。 | 小型系统和标准系统 |
| exec | exec 可执行文件路径 可执行文件传的参数<br>如：exec /system/bin/udevadm trigger | 系统调用命令。 | 小型系统和标准系统 |
| mknode |mknod name { b \| c } Major Minor<br>如mknod path b 0644 1 9| 建立一个目录项和一个特殊文件的对应索引节点。 |标准系统 |
| makedev | makedev major minor<br>如：makedev -v update | 创建静态的设备节点命令，通常位于/dev目录下。| 标准系统 |
| symlink | symlink path1 path2<br>如：symlink /proc/self/fd/0 /dev/stdin | 符号链接命令。 | 标准系统 |
| trigger | trigger jobName<br>如：trigger early-fs | 触发job执行的命令。 | 标准系统 |
| insmod | insmod ko文件<br>如：insmod xxx.ko| 内核模块文件载入命令。 | 标准系统 |
| setparam | setparam paramname paramvalue<br>如：setparam sys.usb.config hdc| 设置系统参数。| 标准系统 |
| load_persist_params | load persist params<br>如：load_persist_params&nbsp;| 加载persist参数。load_persist_params命令后有且仅有一个空格。 | 标准系统 |
| load_param | load params<br>如：load_param /data/test.normal.para| 将文件里的param加载到内存。| 标准系统 |
| load_access_token_id | 如：load_access_token_id&nbsp;| 将access token信息写入data/service/el0/access_token/nativetoken.json文件，load_access_token_id后有且只有一个空格。| 标准系统 |
| ifup | ifup 激活网络接口<br>如：ifup eth0 | 激活指定的网络接口。| 标准系统 |
| mount_fstab | mount_fstab fstab.test<br>如：mount_fstab /vendor/etc/fstab.test| 按照fstab挂载分区的命令。 | 标准系统 |
| umount_fstab | umount_fstab fstab.test<br>如：umount_fstab /vendor/etc/fstab.test | 按照fstab卸载分区的命令。 | 标准系统 |
| restorecon | restorecon file or dir<br>如：restorecon /file | 重新加载selinux 的context。 | 标准系统 |
| stopAllServices | stopAllServices [bool]<br>如：stopAllServices false 或 stopAllServices | 停止所有服务。 | 标准系统 |
| umount |umount path<br>如：umount /vendor | 卸载已经挂载的硬件设备 。 | 标准系统 |
| sync | 如：sync&nbsp; | 同步写入数据到磁盘。sync后有且仅有一个空格。| 标准系统 |
| timer_start | timer_start serviceName<br>如：timer_start console | 启动服务计时器。 | 标准系统 |
| timer_stop | timer_stop serviceName<br>如：timer_stop console | 停止服务计时器。 | 标准系统 |
| init_global_key | init_global_key path 如：init_global_key /data | data分区文件加密key初始化。| 标准系统 |
| init_main_user | 如：init_main_user| 主用户目录加密。| 标准系统 |
| mkswap | mkswap file<br>如：mkswap /swapfile1 | 在一个文件或者设备上建立交换分区。 | 标准系统 |
| swapon | swapon file <br>如：swapon /swapfile1| 激活交换空间。 | 标准系统 |
| loadcfg | loadcfg&nbsp;filePath<br/>如：loadcfg&nbsp;/patch/fstab.cfg | 加载其他cfg文件命令。后面跟着的目标文件大小不得超过50KB，且目前仅支持加载/patch/fstab.cfg，其他文件路径和文件名均不支持。/patch/fstab.cfg文件的每一行都是一条命令，命令类型和格式必须符合本表格描述，命令条数不得超过20条。 | 小型系统 |
### 接口说明
jobs管理属于init启动过程中的一环，是一个流程化的功能，是完全服务于init启动过程的，并不对其他组件提供任何功能接口，其运行逻辑契合cfg中命令组的管理，无法对其他类型管理提供帮助。下述主要介绍其在init当中的调用逻辑。
**表2 job解析接口说明**
| 函数名 | 入参 | 返回值 | 功能 | 支持系统类型 |
|:--------|:-----|:------|:-----|-----|
|void ParseAllJobs(const cJSON *fileRoot)|const cJSON *fileRoot|void|jobs解析总入口。| 小型系统和标准系统 |
|static void ParseJob(const cJSON *jobItem, Job *resJob)|const cJSON *jobItem, Job *resJob|void|校验job是否已存在，解析cmds下命令的功能。| 小型系统 |
|int GetCmdLinesFromJson(const cJSON *root, CmdLines **cmdLines)|const cJSON *root, CmdLines **cmdLines|int| 解析job中cmds命令。当前小型系统使用，标准系统由于涉及trigger功能和condition条件启动功能，并未使用该接口进行命令解析。| 小型系统和标准系统 |
|int ParseTriggerConfig(const cJSON *fileRoot, int (*checkJobValid)(const char *jobName))|const cJSON *fileRoot, int (*checkJobValid)(const char *jobName)|int|解析job中Trigger命令。| 标准系统 |
|static int ParseTrigger_(const TriggerWorkSpace *workSpace, const cJSON *triggerItem, int (*checkJobValid)(const char *jobName))|const TriggerWorkSpace *workSpace, const cJSON *triggerItem, int (*checkJobValid)(const char *jobName)|int|获取job名称，condition属性以及cmds命令组的功能，解析到的job以hash表的形式存储，而命令的保存则使用了队列结构。| 标准系统 |
**表3 job触发接口说明**
| 函数名 | 入参 | 返回值 | 功能 | 支持系统类型 |
|:--------|:-----|:------|:-----| :-----|
|void PostTrigger(EventType type, const char *content, uint32_t contentLen)|EventType type, const char *content, uint32_t contentLen|void|校验名称的有效性并发送触发job事件的功能。| 标准系统 |
|static void SendTriggerEvent(int type, const char *content, uint32_t contentLen)|int type, const char *content, uint32_t contentLen|void|通过系统参数进行整机控制以及服务的启动与停止等。| 标准系统 |
|static void DoTriggerCmd(const struct CmdArgs *ctx)|const struct CmdArgs *ctx|void|trigger命令执行接口| 标准系统 |
|void DoTriggerExec(const char *triggerName)|const char *triggerName|void|仅标准系统可用。通过参数中的job名称找到对应命令组，并将命令推入执行队列依次执行。| 标准系统 |
|void DoJob(const char *jobName)|const char *jobName|void|通过jobName匹配对应job，调用DoCmdByIndex执行其中的命令。| 小型系统 |
|void DoCmdByIndex(int index, const char *cmdContent)|int index, const char *cmdContent|void|拼接参数与命令。| 小型系统和标准系统 |
### 开发实例
下述为cfg文件中jobs配置模板，可验证jobs管理的功能。
```
{
"jobs" : [{ // 基本job
"name" : "stage1",
"cmds" : [
"start service1",
"mkdir dir1"
]
}, { // 条件job
"name" : "param:test.name1=0",
"condition" : "test.name1=0",
"cmds" : [
"chmod 0755 dir1",
"chown root root dir1"
]
}, { // 自定义job
"name" : "param:test.name2=*",
"condition" : "test.name2=*",
"cmds" : [
"chmod 0644 dir1",
"chown system system dir1"
]
}
]
}
```
以上展示了三种job配置的方式，下面对其中的配置差别分别进行介绍：
1. "name"和"cmds"是一个job中的必选项，并且"cmds"中应当包含系统支持的命令，否则就是浪费资源的无意义配置。
2. "condition"是一个job中的可选属性，这一属性的配置代表着该job是一个条件触发的job，不通过代码或trigger命令在固定阶段触发执行，而是在condition中的条件满足后才被触发执行。
3. job的命名需满足一定的规则，对于条件是系统参数的job，以"param:"为前缀。
4. 一个新的job命名需要在其他可执行的job命令组中通过trigger命令触发才可执行，提供的默认trigger命令执行阶段是post-init阶段。
5. 一个已经存在的job名称仍可以在不同文件中继续使用，相同名称的job将会被视为同一job，通过trigger触发时其中的命令合并执行。
6. 条件执行job的condition配置通常是系统参数，可以指定某个系统参数被设定为某个值时该job触发执行，也可以使用"*"符号，代表只要该系统参数被设置，不论为何值，条件都满足，该job可以被触发执行。
7. 在小型系统中，jobs中的post-init 部分不支持trigger命令。
\ No newline at end of file
zh-cn/device-dev/subsystems/subsys-boot-init-plugin.md 0 → 100644
浏览文件 @ fc90db48
# 插件
## 概述
### 基本概念
- begetctl介绍
具体参考[begetctl命令](#table14737791480)。
- bootchart 插件
bootchart是一个用于linux启动过程性能分析的开源工具软件，在系统中自动收集CPU占用率、磁盘吞吐率、进程等信息，并以图形方式显示分析结果，可用作指导优化系统启动过程。begetctl命令参考：[begetctl命令](#table14737791480)。
### 约束与限制
bootchart 只支持标准系统， begetctl 支持小型系统和标准系统。
## 开发指导
### 参数说明
**表1** begetctl 命令说明<a name="table14737791480"></a>
| 命令 | 命令格式和示例 | 说明 |
| :---------- | :---------- |:--------|
| init group test [stage] | init group test | stage参见ServiceStatus。 |
| param ls [-r] [name] | 显示系统参数，例如：<br>查看usb系统参数：begetctl param ls persist.sys.usb | 无 |
| param get [name] | 获取系统参数信息，例如：<br>begetctl param get 或 param get | 无 |
| param set name value| 设置系统参数，例如：<br>begetctl param set ohos.servicectrl.display 1 或 param set ohos.servicectrl.display 1| 无 |
| param wait name [value] [timeout] | 等待系统参数，例如：<br>begetctl param wait persist.sys.usb.config hdc 或 param wait persist.sys.usb.config hdc | timeout默认值：30 |
| param dump [verbose] | dump 系统参数信息，例如：<br>begetctl param dump 或 param dump| 无 |
| param shell [name] | 进入Parameter shell，例如：<br>begetctl param shell 或 param shell| 无 |
| timer_stop servicename | 停止服务计时器，例如：<br>begetctl timer_stop appspawn | servicename长度不超过96字符 |
| timer_start servicename timeout | 启动服务计时器，例如：<br>begetctl timer_start appspawn | servicename长度不超过96；timeout默认值：10s |
| start_service servicename | 启动服务，例如：<br>begetctl start_service appspawn 或 start_service appspawn | 无 |
| stop_service servicename | 停止服务，例如：<br>begetctl stop_service appspawn 或 stop_service appspawn | 无 |
| service_control start servicename | 启动服务，例如：<br>begetctl service_control start appspawn 或 service_control start appspawn | 无 |
| service_control stop servicename | 停止服务，例如：<br>begetctl service_control stop appspawn 或 service_control stop appspawn | 无 |
| misc_daemon --write_logo xxx.rgb | 写入开机logo，例如：<br>begetctl misc_daemon --write_logo logo.rgb 或 misc_daemon --write_logo logo.rgb| rgb文件最大不超过1024*2038，仅支持hi3516dv300 |
| reboot | 重启系统，例如：<br>begetctl reboot 或 reboot|无 |
| reboot shutdown | 关闭系统，例如：<br>begetctl reboot shutdown 或 reboot shutdown |无 |
| reboot suspend | 暂停系统，例如：<br>begetctl reboot suspend 或 reboot suspend | 无 |
| reboot updater | 重新启动并进入updater，例如：<br>begetctl reboot updater 或 reboot updater | 无 |
| reboot updater[:options] | 重新启动并进入updater，例如：<br>begetctl reboot updater 或 reboot updater | 无 |
| reboot flashd | 重新启动并进入flashd，例如：<br>begetctl reboot flashd 或 reboot flashd | 无 |
| reboot flashd[:options] | 重新启动并进入flashd，例如：<br>begetctl reboot flashd 或 reboot flashd | 无 |
| reboot charging | 重新启动并进入charging，例如：<br>begetctl reboot charging 或 reboot charging| 无 |
| reboot loader | 重新启动并进入烧写模式，例如：<br>begetctl reboot loader 或 reboot loader | 无 |
| bootchart stop | 停止图形分析，例如：<br>begetctl bootchart stop | 仅支持rk3568|
| bootchart start | 开始图形分析，例如：<br>begetctl bootchart start | 无 |
| bootchart disable | 图形分析不使能，例如：<br>begetctl bootchart disable | 无 |
| bootchart enable | 图形分析使能，例如：<br>begetctl bootchart enable | 无 |
| sandbox -s service_name | 服务进沙盒，例如 <br>sandbox -s foundation | 无 |
| sandbox -p process_name | 进程进沙盒，例如 <br>sandbox -p /bin/sh | 无 |
| sandbox -n sandbox_name | 进入配置的system或者chipset沙盒，<br>sandbox -n system | 无 |
| sandbox -h | sandbox command help | 无 |
## 开发指导
### 接口说明
**表1** 接口介绍<a name="table14737791479"></a>
| 函数 | 函数解释 |
| ---------- | ---------- |
| void PluginExecCmdByName(const char *name, const char *cmdContent) | 通过名称启动插件。 |
| void PluginExecCmdByCmdIndex(int index, const char *cmdContent) | 通过标志启动插件。 |
| int PluginExecCmd(const char *name, int argc, const char **argv) | 命令启动插件。 |
| int AddCmdExecutor(const char *cmdName, CmdExecutor execCmd) | 添加安装插件命令。 |
### 开发步骤
新增一个插件， 以bootchart为例：
1. 安装so文件， 定义单独文件，实现下面函数。
```c
static int bootchartEarlyHook(int stage, int prio, void *cookie)
{
char enable[4] = {}; // 4 enable size
uint32_t size = sizeof(enable);
SystemReadParam("persist.init.bootchart.enabled", enable, &size);
if (strcmp(enable, "1") != 0) {
PLUGIN_LOGI("bootchart disabled.");
return 0;
}
InitModuleMgrInstall("libbootchart");
PLUGIN_LOGI("bootchart enabled.");
return 0;
}
MODULE_CONSTRUCTOR(void)
{
// Depends on parameter service
InitAddPostPersistParamLoadHook(0, bootchartEarlyHook);
}
```
2. 编译成静态库libbootchart_static，并加入static_modules组。
```
group("static_modules") {
if (!defined(ohos_lite)) {
deps = [ ":libbootchart_static" ]
}
}
```
3. 初始化bootchart插件， 可以安装插件命令。
```c
static int BootchartInit(void)
{
if (g_executorId == -1) {
g_executorId = AddCmdExecutor("bootchart", DoBootchartCmd);
PLUGIN_LOGI("BootchartInit executorId %d", g_executorId);
}
return 0;
}
MODULE_CONSTRUCTOR(void)
{
PLUGIN_LOGI("DoBootchartStart now ...");
BootchartInit();
}
```
4. 退出bootchart插件。
```c
MODULE_DESTRUCTOR(void)
{
PLUGIN_LOGI("DoBootchartStop now ...");
DoBootchartStop();
BootchartExit();
}
```
5. 执行bootchart命令。
```c
static int DoBootchartCmd(int id, const char *name, int argc, const char **argv)
{
PLUGIN_LOGI("DoBootchartCmd argc %d %s", argc, name);
...
return 0;
}
```
### 开发实例
预制条件：
1. 准备bootchart测试环境：linux操作系统下安装python及pycairo pip install pycairo
2. 在linux解压bootchart-master.tar
tar -zxvf bootchart-master.tar
执行步骤：
1. 启动系统。
2. 执行命令行：begetctl bootchart enable
3. 重启系统。
4. 执行命令行：begetctl bootchart stop
5. 执行命令行：begetctl bootchart disable
6. 在/data/bootchart目录下导出如下文件并存放在bootchart文件夹：<br>
header<br>
proc_diskstats.log<br>
proc_ps.log<br>
proc_stat.log<br>
7. 使用tar -zcvf bootchart.tgz * 命令进行打包（只支持linux版本）并将该打包文件拷贝到linux：bootchart-master目录下。
8. 在bootchart-master目录下运行命令：
```
python3 pybootchartgui.py -f pdf bootchart.tgz
```
预期结果：
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;在bootchart-master目录下生成bootchart.pdf。
\ No newline at end of file
zh-cn/device-dev/subsystems/subsys-boot-init-sandbox.md 0 → 100644
浏览文件 @ fc90db48
# 沙盒管理
## 概述
### 功能简介
支持系统组件及芯片组件进程沙盒运行。
### 基本概念
在init里面创建系统组件沙盒和芯片组件沙盒，native服务根据功能进入system沙盒或者chipset沙盒。在system-sandbox.json、chipset-sandbox.json等配置文件中设置沙盒组件中mount bind 的目录或文件，实现沙盒组件通过mount属性进行隔离。同时，提供了一种沙盒调试工具，当需要在沙盒内验证或者进行沙盒相关开发时，方便对需求进行调试、验证、完善。begetctl沙盒命令参考: **[begetctl命令说明](subsys-boot-init-plugin.md#参数说明)**。
### 约束与限制
仅标准系统下使用。
## 开发指导
### 参数说明
**表1** 沙盒配置文件字段解释
| JSON前缀 | 解释 |
| ---------- | ---------- |
| sandbox-root | 沙盒的根目录 |
| mount-bind-paths | mount一个目录 |
| mount-bind-files | mount一个文件 |
| src-path | 需要mount的目录/文件路径 |
| sandbox-path | 沙盒里面需要挂载至的目录/文件 |
| sandbox-flags | mount的挂载标志位, 缺省"bind rec"标志位 |
| target-name | 需要link的目录 |
| link-name | 沙盒内link后的目录 |
**表2** 沙盒配置文件解释
| 沙盒配置文件 | 解释 |
| -------- | -------- |
| chipset-sandbox64.json | 64位系统的芯片沙盒配置文件 |
| chipset-sandbox.json | 32位系统的芯片沙盒配置文件 |
| system-sandbox64.json | 64位系统的系统沙盒配置文件 |
| system-sandbox.json | 32位系统的系统沙盒配置文件 |
### 接口说明
**沙盒的逻辑存储结构：**
```c++
// 主要函数
// name is "system" or "chipset"
bool InitSandboxWithName(const char *name); // 解析JSON至结构体
typedef struct {
mountlist_t *mounts; // 待 mount 的目录
mountlist_t *fileMounts; // 待 mount 的文件
linklist_t *links; // 待 link 的目录
char *rootPath; // 沙盒的根路径 -> /mnt/sandbox/system|vendor|xxx
char name[MAX_BUFFER_LEN]; // 沙盒名称，system沙盒、chipset沙盒等
bool isCreated; // 沙盒创建标志
int ns; // namespace
} sandbox_t;
```
### 开发步骤
1. 沙盒的创建方式
- 创建system或者chipset沙盒，配置对应的system-sandbox.json或者chipset-sandbox.json文件，JSON文件配置参考: [沙盒JSON文件配置](#sandbox)
- 默认情况下，服务的sandbox功能是打开的，如果不想让某个特定的服务不进入沙盒，在cfg中配置sandbox ： 0。当在cfg配置sandbox ： 1，服务依进入沙盒。
```
"sandbox" : 1
```
2. 修改沙盒JSON文件配置
- 查看系统组件沙盒配置文件、芯片组件沙盒配置文件，进入/system/etc/sandbox/ 目录下，cat system-sandbox.json ，cat chipset-sandbox.json; 直接修改对应沙盒配置文件， 重新启动。
对于64位系统，cat system-sandbox64.json ，cat chipset-sandbox64.json。
- 代码路径下：base/startup/init_lite/interfaces/innerkits/sandbox 修改对应沙盒配置文件。
### 开发实例
沙盒JSON文件配置<a name = "sandbox"></a>
```json
{
"sandbox-root" : "/mnt/sandbox/system",
"mount-bind-paths" : [{
"src-path" : "/system/lib/ndk",
"sandbox-path" : "/system/lib/ndk",
"sandbox-flags" : [ "bind", "rec", "private" ]
}],
"mount-bind-files" : [{
"src-path" : "/system/lib/ld-musl-aarch64.so.1",
"sandbox-path" : "/system/lib/ld-musl-aarch64.so.1",
"sandbox-flags" : [ "bind", "rec", "private" ]
}],
"symbol-links" : [{
"target-name" : "/vendor/lib",
"link-name" : "/lib"
}]
}
```
## 常见问题
### 沙盒没有创建成功
**现象描述**
dmesg或者hilog日志中出现 Sandbox %s has not been created.
**原因分析**
沙盒没有创建成功，主要原因是mount与link时出现错误，根据mount与link的主要函数的日志，排查具体问题。
**解决方法**
1. 检查JSON文件是否配置正确。
2. 创建的沙盒是否受支持。
\ No newline at end of file
zh-cn/device-dev/subsystems/subsys-boot-init-service.md 0 → 100644
浏览文件 @ fc90db48
# 服务管理
## 概述
### 功能简介
服务配置支持按需配置服务，并根据业务场景，支持多种增值服务。当前支持的增值服务包括启动控制、按需启动、命令执行、定时启动、fd代持、**[沙盒](subsys-boot-init-sandbox.md)**。
### 基本概念
- init服务参数选项列表
参见[service字段说明](#table14737791471)。
- init服务启动控制(仅标准系统以上提供)<a name = "section56901555918">
init会根据用户的服务配置，把服务分成三类，在不同的阶段并行启动。
- “boot”类型：对应系统中需要优先启动的服务，该类服务在“init”阶段启动。
- “normal”类型：默认配置，对应系统中的普通服务，该类服务在“post-init"阶段启动。
- “condition”类型：必须通过启动命令启动，通过在jobs中添加“start xxxx”来启动对应服务。
- init服务支持命令执行(仅标准系统以上提供)<a name="section56901555919"></a>
init提供服务命令执行能力，在服务执行的不同阶段执行不同的命令。
- "on-start"：在服务进程被fork后在子进程中执行，只对该进程产生影响。
- "on-stop"：在服务停止时执行，在init进程中执行。
- "on-restart"：在服务重启时执行，在init进程中执行。
参考配置如下：
```
"services" : [{
"name" : "serviceName",
"path" : ["/system/bin/serviceName"]
"jobs" : {
"on-boot" : "boot",
"on-start" : "services:serviceName_start",
"on-stop" : "services:serviceName_stop",
"on-restart" : "services:serviceName_restart"
}
},
```
通过并行启动和命令执行能力，可以实现进程的并行启动。
- init按需启动(仅标准系统以上提供) <a name="section56901555920">
配置按需启动后，init进程不会启动对应的服务，只有服务被需要时才会被拉起。通过"ondemand"标记来控制服务是否被拉起。
“ondemand”参考配置如下：
```
"services" : [{
"name" : "serviceName",
"path" : ["/system/bin/serviceName"]
"ondemand" : true
}]
```
- SA进程按需启动
具体参考 **[samgr组件(说明3)](https://gitee.com/openharmony/distributedschedule_samgr/blob/master/README_zh.md)**。
- socket进程按需启动
1. init进程在pre-fork阶段为socket类进程创建好socket，init进程中监听创建好的socket上的读写事件。
2. socket上有读写事件后，init进程拉起socket进程对应的native服务，并取消对socket的监听，将socket交由相应的native服务管理。
3. native服务无报文处理后，可以自动退出。init进程在回收子进程时会根据服务配置重新监听socket。
- 热插拔服务进程按需启动
进程可根据系统参数的变化进行热插拔事件按需启动处理。
- init进程启动&amp;回收能力增强
进程启动时，支持在配置文件中配置服务进程的绑核、优先级、MAC信息以及AccessToken信息。
- init提供修改\*.cfg配置文件，为服务进程提供cpu绑核功能。
- init提供修改\*.cfg配置文件，为服务进程提供优先级设置。
- init提供修改\*.cfg配置文件，为服务提供MAC信息设置，即服务的SELinux标签（需要selinux支持）。
- init提供修改\*.cfg配置文件，为服务提供设置AccessToken, 为系统服务进程设置其分布式Capability能力（仅标准系统以上提供）。
- init提供修改\*.cfg配置文件，为服务提供抑制机制。
服务进程启动&回收能力增强配置，如下：
```
"services" : [{
"name" : "serviceName",
"path" : ["/system/bin/serviceName"]
"importance" : 1, // 服务进程提供优先级设置
"cpucore" : [0], // 服务进程提供cpu绑核功能
"critical" : [1, 5, 10], // 服务提供抑制机制
"apl" : "normal", // 系统服务进程设置其分布式Capability能力
"d-caps" : ["OHOS_DMS"], // 系统服务进程设置其分布式Capability能力
"secon" : "u:r:distributedsche:s0" // 服务的SELinux标签， "u:r:distributedsche:s0"为要设置的SELinux标签信息
}
```
- init FD代持（仅标准系统以上提供）
FD代持是按需启动的一个辅助扩展机制，按需启动进程可以保持退出前的fd状态句柄不丢失。按需启动进程退出前可将fd发送给init代持，再次启动后再从init获取fd。
init提供了相关接口供服务调用，服务进程退出前调用接口将fd通过支持IPC通信的socket发送给init代持，待该服务重新启动时，init将持有的该服务相关的fd句柄通过同样的方式返回给服务。相关接口参考：[FD代持接口介绍](#table14737791479)。
- 定时启动
通过约定时间拉起服务， 若服务已拉起， 则不在重新拉起服务。具体命令参考： **[begetctl命令说明](subsys-boot-init-plugin#参数说明)** 。
```
timer_start servicename timeout
```
- 沙盒
具体参考 **[沙盒指导](subsys-boot-init-sandbox.md)**。
### 约束与限制
仅限小型系统、标准系统下使用。
## 开发指导
### 场景介绍
通过对*.cfg文件的解析， 获取service中的属性， 设置并启动service。
### 参数说明
**表1** service字段说明<a name="table14737791471"></a>
| 字段名 | 字段说明 | 字段解释 | 支持系统类型 |
| ---------- |-------- | --------| --------|
| name | 当前服务的服务名。(必选) | 类型：字符串； 服务名非空且长度<=32字节。| 小型系统和标准系统 |
| path | 当前服务的可执行文件全路径和参数，数组形式。 (必选) | 确保第一个数组元素为可执行文件路径、数组元素个数<=20。 <br> 每个元素为字符串形式以及每个字符串长度<=64字节。| 小型系统和标准系统 |
| uid | 当前服务进程的uid值。 | 类型：int、字符串。 | 小型系统和标准系统 |
| gid | 当前服务进程的gid值。 | 类型：int、int[]、字符串、字符串数组。 | 小型系统和标准系统 |
| once | 当前服务进程是否为一次性进程。 | 1：一次性进程，当该进程退出时，init不会重新启动该服务进程。 <br>0 : 常驻进程，当该进程退出时，init收到SIGCHLD信号并重新启动该服务进程。 | 小型系统和标准系统 |
| importance | 当前服务优先级 | <li>标准系统中: 服务优先级取值范围 [-20， 19]，超出为无效设置。<li>小型系统中：0 : 非重要进程；非0 : 重要进程 | 小型系统和标准系统 |
| caps | 当前服务所需的capability值，根据安全子系统已支持的capability，评估所需的capability，遵循最小权限原则配置。| 类型：数字或者字符串数组，在配置数字时，按linux标准的capability进行配置。字符串时，使用标准定义的宏的名字进行配置。 | 小型系统和标准系统 |
| critical | 为服务提供抑制机制，服务在配置时间 T 内，频繁重启次数超过设置次数 N 重启系统。 | <li>标准系统中： 类型：int[]，如："critical" : [M, N, T]，其中M：使能标志位（0：不使能；1：使能）， N：频繁拉起服务次数， T：时间(单位：秒)。M > 0; N > 0。 <li> 小型系统中 & 标准系统中：类型：int，如："critical" : M，其中 M：使能标志位（0：不使能；1：使能）。 默认拉起服务次数：4次， 时间：20秒 。| 标准系统 |
| cpucore | 服务需要的绑定的cpu核心数 | 类型：int型数组， 如"cpucore" : [N1, N2, ...], N1， N2均为需要绑定的cpu核索引， 如单核设备 cpucore : [0]。 | 标准系统 |
| d-caps | 服务分布式能力（仅标准系统以上提供）。| 类型：字符串数组， 如 "d-caps" : ["OHOS_DMS"]。 | 标准系统 |
| apl | 服务能力特权级别（仅标准系统以上提供）。 | 类型：字符串， 如 "apl" : "system_core"。<br> 目前支持"system_core"（默认值）, "normal", "system_basic"。 | 标准系统 |
| start-mode | 服务的启动模式（仅标准系统以上提供）。 | 类型：字符串， 如 "start-mode" : "condition"。<br>目前支持"boot", "normal", "condition"。具体说明参考：[init服务启动控制](#section56901555918)。 | 标准系统 |
| ondemand | 按需启动服务的标志。 | 类型：bool，如"ondemand" : true，小型系统只在Linux内核上支持。具体说明参考：[init服务按需启动](#section56901555920)。| 小型系统和标准系统 |
| disable | 预留字段，无实际意义。 | 无。 | 小型系统和标准系统 |
| sandbox | 沙盒功能是否打开。 | 1：打开服务的沙盒功能 （默认值）。<br>0：关闭服务的沙盒功能。 | 标准系统 |
**表2** socket字段说明
| 字段名 | 说明 |
| -------- | -------- |
| name | 当前socket的命名，不要求必须与服务同名，与服务名同样须满足非空且长度<=32字节。|
| family | socket所属的地址族，目前支持的为服务创建的socket有AF_UNIX和AF_NETLINK族。|
| type | socket的类型，目前支持的类型有基于连接的SOCK_SEQPACKET和SOCK_STREAM，还有基于UDP无连接的SOCK_DGRAM。|
| protocol | socket通信遵循的协议类型，在无特殊需求的情况下，该值可配置为default缺省值，因为socket接口会自动根据socket地址族和类型选择合适的协议。此处除了default，并且支持NETLINK_KOBJECT_UEVENT协议类型。|
| permissions | socket节点文件的权限。此项配置仅对如AF_UNIX地址族等有实体节点文件的socket类型有效。|
| uid | socket节点文件的用户ID。此项配置仅对如AF_UNIX地址族等有实体节点文件的socket类型有效。|
| gid | socket节点文件的组ID。此项配置仅对如AF_UNIX地址族等有实体节点文件的socket类型有效。|
| option | socket的可选配置。在调用setsockopt接口时传入设置，目前支持的option选项有SOCKET_OPTION_PASSCRED、SOCKET_OPTION_RCVBUFFORCE、SOCK_CLOEXEC和SOCK_NONBLOCK。|
### 接口说明
**表3** FD代持接口介绍<a name="table14737791479"></a>
| 函数名 | 函数解释 | 参数解释 |
| ---------- | ---------- |--------|
| int *ServiceGetFd(const char *serviceName, size_t *outfdCount) | 获取init代持的fd | 返回值：成功返回fd数组指针，失败返回NULL。备注：需手动释放<br>参数：<br> serviceName: 服务名<br>outfdCount: 返回的fd数组长度 |
| int ServiceSaveFd(const char *serviceName, int *fds, int fdCount) | 请求init代持fd | 返回值：成功返回0，失败返回-1 <br> 参数：<br> serviceName: 服务名 <br> fds: 需要init代持的fd数组指针<br>fdCount: fd数组长度
| int ServiceSaveFdWithPoll(const char *serviceName, int *fds, int fdCount) | 使用poll方式，请求fd代持 | 返回值：成功返回0，失败返回-1 <br> 参数：<br> serviceName: 服务名 <br> fds: fd代持数组指针 <br> fdCount 数组长度
**表4** 服务控制接口介绍
| 函数名 | 函数解释 | 参数解释 |
| :---------- | :---------- |:--------|
| int ServiceControlWithExtra(const char *serviceName, int action, const char *extArgv[], int extArgc) | 配置服务参数 | 返回值：成功返回0，失败返回-1 <br> 参数: <br> serviceName: 服务名 <br> action: 服务行为（"start", "stop", "restart"） <br> extArgv: 参数数组 <br> extArgc: 参数个数 |
| int ServiceControl(const char *serviceName, int action) | 控制服务行为 | 返回值：成功返回0，失败返回-1 <br> 参数：<br> serviceName: 服务名 <br> action: 服务行为（"start"， "stop", "restart") |
| int ServiceWaitForStatus(const char *serviceName, ServiceStatus status, int waitTimeout) | 等待服务状态 | 返回值：成功返回0， 失败返回-1。<br> 参数：<br>serviceName: 服务名 <br> status: 返回服务状态 <br> 超时时间 |
| int ServiceSetReady(const char *serviceName) | 设置服务准备 | 返回值：成功返回0，失败返回-1 <br> 参数：<br> serviceName: 服务名 |
| int StartServiceByTimer(const char *serviceName, uint64_t timeout) | 定时启动服务 | 返回值：成功返回0，失败返回-1 <br> 参数: <br> serviceName: 服务名 <br> timeout: 超时时间 |
| int StopServiceTimer(const char *serviceName) | 停止服务计时器 | 返回值：成功返回0，失败返回-1 <br> 参数：<br> serviceName: 服务名 |
### 开发步骤
此处以要新增一个名为MySystemApp的系统服务为例进行说明，使用如下配置：
```
{
"jobs" : [{
"name" : "pre-init",
"cmds" : [
"mkdir /storage/MyDir", // MySystemApp服务启动之前需要先创建文件夹，因此放在 “pre-init”中进行
"chmod 0600 /storage/MyDir", // MySystemApp服务要求该文件夹只有本用户和属组才可读写，因此需要修改权限
"chown 10 10 /storage/MyDir"
]
}, {
"name" : "init",
"cmds" : [
"start MySystemApp" // 在init中启动该系统服务
]
}, {
"name" : "post-init",
"cmds" : [] // MySystemApp系统服务启动后无需进行其他操作，因此不用配置“post-init”
}
],
"services" : [{
"name" : "MySystemApp", // 系统服务名称
"path" : ["/bin/MySystemAppExe", "param1", "param2", "param3"], // MySystemApp系统服务的可执行文件路径为"/bin/MySystemAppExe"，其启动需要传入三个参数，分别是"param1"、"param2"和"param3
"socket" : [{
"name" : "ueventd",
"family" : "AF_NETLINK",
"type" : "SOCK_DGRAM",
"protocol" : "NETLINK_KOBJECT_UEVENT",
"permissions" : "0660",
"uid" : "system",
"gid" : "system",
"option" : [
"SOCKET_OPTION_PASSCRED",
"SOCKET_OPTION_RCVBUFFORCE",
"SOCK_CLOEXEC",
"SOCK_NONBLOCK"
]
}],
"uid" : 20, // MySystemApp系统服务的uid是20
"gid" : 20, // MySystemApp系统服务的gid是20
"once" : 0, // MySystemApp系统服务的非一次性进程，即如果MySystemApp系统服务因任何原因退出，init进程需要将其重新拉起
"importance" : 0, // MySystemApp系统服务不是关键系统进程，即如果MySystemApp系统服务因任何原因退出，init进程无需重启单板
"caps" : [], // MySystemApp系统服务不需要任何capability权限（即MySystemApp系统服务不涉及与capability相关的操作）
"start-mode" : "condition",
"critical": [1, 2, 10], //MySystemApp系统服务的critical配置，需传入三个参数， 分别为使能：1， 执行次数：2， 执行时间：10
"cpucore" : [0, 1], // 设备为双核， 且都绑定cpu
"apl" : "system_core",
"d-caps" : ["OHOS_DMS"],
"jobs" : {
"on-boot" : "boot",
"on-start" : "services:MySystemApp_start",
"on-stop" : "services:MySystemApp_stop",
"on-restart" : "services:MySystemApp_restart"
}
}
]
}
```
完成配置后，编译出包烧写单板：
1. 启动后使用task -a（liteos-a版本）或ps命令（linux版本）查看是否MySystemApp系统服务进程已启动。
2. 使用kill命令将上述新增的MySystemApp进程杀死，观察该进程是否会被重新拉起（此处应该为重新拉起）。
3. 使用kill命令将上述新增的MySystemApp进程杀死，观察是否会导致单板重启（此处应该为不重启）。
## 常见问题
### 服务不存在
**现象描述**
kernel日志打印 "Failed get servName"。
**原因分析**
在init中查找对应的代码位置，发现是服务不存在。
**解决方法**
1. 确认服务是否在cfg中正确配置。
2. 服务的cfg文件是否正常加载。
3. cfg文件格式是否正确。
### 请求其他服务代持fd，init有报错
**现象描述**
kernel日志打印 "Service ' xxx '(pid = xxx) is not valid or request with unexpected process(pid = xxx)"。
**原因分析**
kernel日志打印，都是由init 打印。在init中查找对应的代码位置。发现是其他服务代持fd。
**解决方法**
只支持代持本服务的fd，不允许让其他服务代持fd。
\ No newline at end of file
zh-cn/device-dev/subsystems/subsys-boot-init-sysparam.md 0 → 100644
浏览文件 @ fc90db48
# 系统参数
## 概述
### 功能简介
OHOS系统参数为各系统服务提供简单易用的键值对访问接口，使得各个系统服务可以通过各自的系统参数来进行业务功能的配置。
### 基本概念
图1 系统参数操作原语
![系统参数操作原语](figures/系统参数操作原语.png)
**表1** 系统参数操作原语说明
| 功能 | 说明 |
| -------- | -------- |
| get | 获取系统参数的值 |
| set | 设置系统参数的值 |
| wait | 同步等待系统参数的值变更 |
| watch | 异步观察系统参数的值变更 |
#### 系统参数定义
- 系统参数命名格式
系统参数名称采用点分格式，由多段组成，每一段可以由字母、数字、下划线组成，总长度不超过96字节；系统参数名称分为两类：
**表2** 系统参数名称
| 类别 | 名称 | 示例 | 说明 |
| -------- | -------- | -------- | -------- |
| 参数名称 | Parameter Name | const.product.**name** | 完整的系统参数名称，末尾不是"."。 |
| 参数目录 | Parameter Directory | const.product **.** | 以"."结尾，标识相同前缀的所有系统参数集合。 |
- 系统参数类型
系统参数一共分为三大类：
**表3** 系统参数分类
| 类别 | 前缀 | 说明 |
| -------- | -------- | -------- |
| 常量 | const. | 常量参数，一旦赋值后续不会再变更；值最大长度为4096字节（包括结束符）。 |
| 可写 | 其它 | 可写参数，重启后丢失，值最大长度96字节（包括结束符）。|
| 可持久化 | persist. | 可写并可持久化保存参数，重启后不会丢失，值最大长度96字节（包括结束符）。|
每个系统参数名称总体格式如下：
```
[ const | persist ].$sub_system.$desc
```
$sub_system为子系统或模块的名称。
$desc为子系统或模块下参数的描述字符，可以为点分格式进行分级描述。
#### 系统参数定义规则
每个子系统定义各自模块的系统参数，包括系统参数名称、默认值以及系统参数的权限访问信息。
- 系统参数值定义文件
- 系统参数值定义文件后缀名为".para" ，其格式示例如下：
```shell
# This is comment
const.product.name=OHOS-PRODUCT
const.os.version.api=26
const.telephony.enable=false|true
const.test.withblank=My Value
const.test.withcomment=MyValue # This should be ommitted
const.test.multiline="This is a multiline parameter.
Line2 value.
Last line."
```
- 系统参数必须通过完整的系统参数命令来赋值，赋值方式分为三大类：
**表4** 系统参数赋值方式
| 类别 | 示例 | 说明 |
| -------- | -------- | -------- |
| 字符串 | const.product.name=OHOS-PRODUCT | 多行字符串需要通过引号扩起来。 |
| 数字 | const.os.version.api=26 | 数字不需要。|
| 布尔 | const.telephony.enable=false | 布尔型的可以为0,1,false,true。|
- 系统参数DAC访问控制定义文件
当前系统参数的访问权限控制通过自主访问控制（Discretionary Access Control）方式管理，访问权限定义文件后缀名为".para.dac" ，示例如下：
```java
const.product.="root:root:660"
```
如上所示，可以通过参数路径为相同前缀的所有系统参数定义一类访问权限信息；DAC信息通过":"分三段来描述，分别为参数的user，group以及UGO规则信息。
UGO规则信息每一位的定义如下：
**图2** UGO规则信息
![UGO规则信息](figures/系统参数DAC.png)
- 默认参数加载
系统参数的加载顺序如下：
**表5** 系统参数加载顺序
| 类别 | 路径 | 说明 |
| -------- | -------- | -------- |
| 内核参数 | /proc/cmdline | 将内核参数中的部分值转化成系统参数，并保存。内核参数中.xxx=valXXX类型的参数都转换成ohos.boot.xxx=valXXX系统参数。 |
| OS系统参数 | /system/etc/param/ohos_const/*.para | OS固定系统参数值参数优先加载。 |
| vendor参数 | /vendor/etc/param/*.para | 厂商定义的系统参数次优先级加载。 |
| system参数 | /system/etc/param/*.para | 加载各子系统定义的参数参数。如果系统参数已经存在，则忽略掉。 |
| persist参数 | /data/parameters/ | 如果持久化参数存在，则最后加载持久化系统参数。持久化系统参数会覆盖加载的默认系统参数。 |
### 约束与限制
仅限小型系统、标准系统下使用。
## 开发指导
### 场景介绍
设定特定的系统参数
### 接口说明
- Shell命令接口
通过shell命令中可直接操作系统参数（只在标准系统提供）。系统参数shell命令如下表所示：
**表6** 系统参数shell命令说明
| 功能 | 说明 |
| -------- | -------- |
| param get [**key**] | 获取指定key名称的系统参数值；如果不指定任何name，则返回所有系统参数值。 |
| param set **key value** | 设置指定key名称的参数值为value。 |
| param wait **key** **value** | 同步等待指定key名称的系统参数值与value匹配。value可支持模糊匹配，如"*"表示任何值，"val\*"表示只匹配前三个val字符。 |
| param watch | 异步观察系统参数的值变更。|
- syspara系统接口
在Coding中可以调用下列函数接口，获取对应的系统参数值（系统参数接口返回的为const字符串，不支持free操作）。
**表7** 系统属性接口说明
| 接口名 | 描述 |
| -------- | -------- |
| int&nbsp;GetParameter(const&nbsp;char\*&nbsp;key,&nbsp;const&nbsp;char\*&nbsp;def,&nbsp;char\*&nbsp;value,&nbsp;unsigned&nbsp;int&nbsp;len) | 获取系统参数。 |
| int&nbsp;SetParameter(const&nbsp;char\*&nbsp;key,&nbsp;const&nbsp;char\*&nbsp;value) | 设置/更新系统参数。 |
| const&nbsp;char\*&nbsp;GetDeviceType(void) | 返回当前设备类型。 |
| const&nbsp;char\*&nbsp;GetManufacture(void) | 返回当前设备生产厂家信息。 |
| const&nbsp;char\*&nbsp;GetBrand(void) | 返回当前设备品牌信息。 |
| const&nbsp;char\*&nbsp;GetMarketName(void) | 返回当前设备传播名。 |
| const&nbsp;char\*&nbsp;GetProductSeries(void) | 返回当前设备产品系列名。 |
| const&nbsp;char\*&nbsp;GetProductModel(void) | 返回当前设备认证型号。 |
| const&nbsp;char\*&nbsp;GetSoftwareModel(void) | 返回当前设备内部软件子型号。 |
| const&nbsp;char\*&nbsp;GetHardwareModel(void) | 返回当前设备硬件版本号。 |
| const&nbsp;char\*&nbsp;GetHardwareProfile(void) | 返回当前设备硬件profile。 |
| const&nbsp;char\*&nbsp;GetSerial(void) | 返回当前设备序列号（SN号）。 |
| const&nbsp;char\*&nbsp;GetOSFullName(void) | 返回操作系统名。 |
| const&nbsp;char\*&nbsp;GetDisplayVersion(void) | 返回当前设备用户可见的软件版本号。 |
| const&nbsp;char\*&nbsp;GetBootloaderVersion(void) | 返回当前设备Bootloader版本号。 |
| const&nbsp;char\*&nbsp;GetSecurityPatchTag(void) | 返回安全补丁标签。 |
| const&nbsp;char\*&nbsp;GetAbiList(void) | 返回当前设备支持的指令集（Abi）列表。 |
| int&nbsp;GetSdkApiVersion(void) | 返回与当前系统软件匹配的SDK&nbsp;API&nbsp;版本号。 |
| int&nbsp;GetFirstApiVersion(void) | 返回系统软件首版本SDK&nbsp;API&nbsp;版本号。 |
| const&nbsp;char\*&nbsp;GetIncrementalVersion(void) | 返回差异版本号。 |
| const&nbsp;char\*&nbsp;GetVersionId(void) | 返回版本id。 |
| const&nbsp;char\*&nbsp;GetBuildType(void) | 返回构建类型。 |
| const&nbsp;char\*&nbsp;GetBuildUser(void) | 返回构建账户用户名。 |
| const&nbsp;char\*&nbsp;GetBuildHost(void) | 返回构建主机名。 |
| const&nbsp;char\*&nbsp;GetBuildTime(void) | 返回构建时间。 |
| const&nbsp;char\*&nbsp;GetBuildRootHash(void) | 返回当前版本hash。 |
| const&nbsp;char\*&nbsp;GetOsReleaseType(void) | 返回系统发布类型。 |
| int&nbsp;GetDevUdid(char&nbsp;\*udid,&nbsp;int&nbsp;size) | 获取设备udid。 |
| const char *AclGetSerial(void); | 返回当前设备序列号（SN号）（带访问权限检查）。 |
| int AclGetDevUdid(char *udid, int size); | 获取设备udid（带访问权限检查）。 |
### 开发步骤
1. 系统参数定义
通过定义子系统或者产品的.para和.para.dac文件，实现默认系统参数的定义和权限控制。
​ 在标准系统上通过ohos_prebuilt_para模版安装配置文件到到/etc/param/目录下，GN脚本示例如下：
```go
import("//base/startup/init_lite/services/etc/param/param_fixer.gni")
ohos_prebuilt_para("ohos.para") {
source = "//base/startup/init_lite/services/etc/ohos.para"
part_name = "init"
module_install_dir = "etc/param"
}
ohos_prebuilt_para("ohos.para.dac") {
source = "//base/startup/init_lite/services/etc/ohos.para.dac"
part_name = "init"
module_install_dir = "etc/param"
}
```
在小系统上，通过copy命令，把对应的系统参数定义文件拷贝到system/etc/param目录下
```go
copy("ohos.para") {
sources = [ "//base/startup/init_lite/services/etc/param/ohos.para" ]
outputs = [ "$root_out_dir/system/etc/param/ohos.para" ]
}
copy("ohos.para.dac") {
sources = [ "//base/startup/init_lite/services/etc/param/ohos.para.dac" ]
outputs = [ "$root_out_dir/system/etc/param/ohos.para.dac" ]
}
```
在mini系统上，通过action把所有定义的默认系统参数转化成头文件，并编译到系统中
```go
action("lite_const_param_to") {
script = "//base/startup/init_lite/scripts/param_cfg_to_code.py"
args = [
"--source",
rebase_path(
"//base/startup/init_lite/services/etc_lite/param/ohos_const/ohospara"),
"--dest_dir",
rebase_path("$root_out_dir/gen/init_lite/"),
"--priority",
"0",
]
outputs = [ "$target_gen_dir/${target_name}_param_cfg_to_code.log" ]
}
```
2. 系统参数使用实例
```
// set && get
char key1[] = "rw.sys.version";
char value1[] = "10.1.0";
int ret = SetParameter(key1, value1);
char valueGet1[128] = {0};
ret = GetParameter(key1, "version=10.1.0", valueGet1, 128);
// get sysparm
char* value1 = GetDeviceType();
printf("Product type =%s\n", value1);
char* value2 = GetManufacture();
printf("Manufacture =%s\n", value2);
char* value3 = GetBrand();
printf("GetBrand =%s\n", value3);
char* value4 = GetMarketName();
printf("MarketName =%s\n", value4);
char* value5 = GetProductSeries();
printf("ProductSeries =%s\n", value5);
char* value6 = GetProductModel();
printf("ProductModel =%s\n", value6);
char* value7 = GetSoftwareModel();
printf("SoftwareModel =%s\n", value7);
char* value8 = GetHardwareModel();
printf("HardwareModel =%s\n", value8);
char* value9 = GetHardwareProfile();
printf("Software profile =%s\n", value9);
char* value10 = GetSerial();
printf("Serial =%s\n", value10);
char* value11 = GetOSFullName();
printf("OS name =%s\n", value11);
char* value12 = GetDisplayVersion();
printf("Display version =%s\n", value12);
char* value13 = GetBootloaderVersion();
printf("bootloader version =%s\n", value13);
char* value14 = GetSecurityPatchTag();
printf("secure patch level =%s\n", value14);
char* value15 = GetAbiList();
printf("abi list =%s\n", value15);
int value16 = GetFirstApiVersion();
printf("first api level =%d\n", value16);
char* value17 = GetIncrementalVersion();
printf("Incremental version = %s\n", value17);
char* value18 = GetVersionId();
printf("formal id =%s\n", value18);
char* value19 = GetBuildType();
printf("build type =%s\n", value19);
char* value20 = GetBuildUser();
printf("build user =%s\n", value20);
char* value21 = GetBuildHost();
printf("Build host = %s\n", value21);
char* value22 = GetBuildTime();
printf("build time =%s\n", value22);
char* value23 = GetBuildRootHash();
printf("build root later..., %s\n", value23);
char* value24 = GetOsReleaseType();
printf("OS release type =%s\n", value24);
char* value25 = GetOsReleaseType();
printf("OS release type =%s\n", value25);
char value26[65] = {0};
GetDevUdid(value26, 65);
printf("device udid =%s\n", value26);
```
\ No newline at end of file
zh-cn/device-dev/subsystems/subsys-boot-init.md
浏览文件 @ fc90db48
# init启动引导组件
# Init启动引导组件
## 功能说明
- **[引导启动配置文件](subsys-boot-init-cfg.md)**
init启动引导组件负责在系统启动阶段启动关键服务进程。 若用户需要新增随开机自启动的系统服务，可添加新的配置文件xxx.cfg，系统会自动分析对应的cfg文件，并按照cfg文件启动对应的服务。
- **[jobs管理](subsys-boot-init-jobs.md)**
- init启动引导的配置文件
- **[服务管理](subsys-boot-init-service.md)**
init启动引导组件配置文件包含了所有需要由init进程启动的系统关键服务的服务名、可执行文件路径、权限和其他信息。烧写单板后可在“/etc/“目录下找到，文件名称为init.cfg，采用json格式，文件大小目前限制在100KB以内。
- **[系统参数](subsys-boot-init-sysparam.md)**
init进程启动后读取/etc/init.cfg，然后解析其json格式内容，并根据解析结果依次加载系统服务。
- **[沙盒管理](subsys-boot-init-sandbox.md)**
各模块需要配置或添加关键服务时，可以在对应模块的cfg文件进行配置。编译过程中会将配置后的文件拷贝到/system/etc/init目录下，单板中可在"/etc/init/"目录下查找到对应的cfg文件。
对于单板中/etc/init下存在的cfg文件，init进程会逐一解析。下面分别介绍一下init扫描cfg文件的规则和cfg文件内容的具体组成格式。
- cfg文件扫描规则
对于标准系统和小型系统，cfg文件扫描是共用一个相同的接口，接口代码如下：
```
void ReadConfig(void)
{
// parse cfg
if (InChargerMode() == 1) {
ParseInitCfg(INIT_CONFIGURATION_FILE, NULL);
ReadFileInDir(OTHER_CHARGE_PATH, ".cfg", ParseInitCfg, NULL);
} else if (InUpdaterMode() == 0) {
ParseInitCfg(INIT_CONFIGURATION_FILE, NULL);
ReadFileInDir(OTHER_CFG_PATH, ".cfg", ParseInitCfg, NULL);
ReadFileInDir("/vendor/etc/init", ".cfg", ParseInitCfg, NULL);
} else {
ReadFileInDir("/etc", ".cfg", ParseInitCfg, NULL);
}
}
```
以下是这段代码中的宏定义：
```
#define INIT_CONFIGURATION_FILE "/etc/init.cfg"
#define OTHER_CHARGE_PATH "/system/etc/charge"
#define OTHER_CFG_PATH "/system/etc/init"
```
对于充电模式和升级模式下cfg的扫描此处不作详细说明，我们关注正常系统启动时init扫描cfg文件的规则。
1. 对于/etc/init.cfg文件，是应当最先解析，因此直接调用解析接口解析该文件。
2. 对于/etc/init目录（注：/etc是指向/system/etc的一个符号链接，可以把它们看作是等价的），init进程会遍历该目录下的文件，匹配文件的后缀名，匹配到cfg文件时就会调用解析接口对该文件进行解析。
3. init还会遍历/vendor/etc/init目录下的cfg文件并进行解析，这个目录下的cfg文件应当是与硬件平台相关的。
- cfg文件的组成格式
下面展示一个cfg文件的框架：
```
{
"import" : [
"/etc/init.xxx.cfg",
"/vendor/etc/init.${ohos.boot.hardware}.cfg"
],
"jobs" : [{
"name" : "example-stage",
"cmds" : [
"write /example/file 0",
"start example"
]
}
],
"services" : [{
"name" : "example",
"path" : ["/system/bin/example"],
}
]
}
```
前面已经提到，cfg文件是json格式的文本文件。对于启动组件来说，init进程能够解析的cfg文件中的内容主要包括3种json对象，其对象名分别为"import", "jobs", "services"。下面逐一讲解这3个部分。
1. "import": 导入其他cfg文件。一个cfg文件中导入的其他cfg文件，会在当前cfg文件解析完成后，按顺序继续解析。
2. "jobs": 带名字的命令组。一个job被执行时，会按照先后顺序逐条执行"cmds"中的命令。触发执行job的方式在下文中有详细介绍。
3. "services": 服务。最简单的服务可以只有一个名字和一个可执行文件路径。一个服务的基本运行逻辑是在init进程中fork一个子进程，然后在子进程中执行路径中的可执行文件。服务是启动组件中的核心内容，cfg中服务的配置还包括了各种各样的属性，服务的控制方式也涵盖了多方面的内容，这些都将在下文中展开详细的叙述。
- init服务启动控制(仅标准系统以上提供)<a name = "section56901555918">
init会根据用户的服务配置，把服务分成三类，在不同的阶段进行启动。
- “boot”类型：对应系统中需要优先启动的服务，该类服务在“init”阶段启动。
- “normal”类型：默认配置，对应系统中的普通服务，该类服务在“post-init"阶段启动。
- “condition”类型：表示服务按照条件启动。对有特殊要求的服务，可以直接通过start xxx 命令执行启动，一般在条件“job”或者在“init”的某个阶段使用命令启动。
服务间或服务与命令之间存在依赖关系，需要通过"condition"描述服务，配置参考如下：
```
"services" : [{
"name" : "serviceName",
"start-mode" : "condition",
},
```
- init服务并行控制(仅标准系统以上提供)<a name="section56901555919"></a>
init提供服务并行处理能力，启动服务在不同的阶段执行job的能力。
- “on-start”：在服务进程被fork后执行，不同服务的on-start job可以并行执行（在服务的子进程中执行，只对该进程产生影响）。
- “on-stop”：在服务停止时执行。
- "on-restart"：在服务重启时执行。
参考配置如下：
```
"services" : [{
"name" : "serviceName",
"jobs" : {
"on-boot" : "boot",
"on-start" : "services:serviceName_start",
"on-stop" : "services:serviceName_stop",
"on-restart" : "services:serviceName_restart"
}
},
```
- init按需启动(仅标准系统以上提供) <a name="section56901555920">
由init管理的服务支持按需启动，按需启动的服务不会在系统启动过程中主动被拉起，而是当某些事件发生时才会被init按需拉起，触发服务启动的事件可能是被init监听的相关socket有消息上报、samgr收到客户端的请求需要拉起SA服务等情况。
"ondemand"：按需启动服务的标志，一个服务配置了该属性值为true的时候，服务不再需要配置start命令来拉起，而是被监听的相应事件发生时才会被拉起。
“ondemand”参考配置如下：
```
"services" : [{
"name" : "serviceName",
"ondemand" : true,
}]
```
- 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网络数据。
- 热插拔服务进程按需启动 
进程可根据系统参数的变化进行热插拔事件按需启动处理。
- init 进程启动&amp;回收能力增强
进程启动时，支持在配置文件中配置服务进程的绑核、优先级、MAC信息以及AccessToken信息。
- init提供修改\*.cfg配置文件，为服务进程提供cpu绑核功能。
- init提供修改\*.cfg配置文件，为服务进程提供优先级设置。
- init提供修改\*.cfg配置文件，为服务提供MAC信息设置，即服务的SELinux标签。
- init提供修改\*.cfg配置文件，为服务提供设置AccessToken, 为系统服务进程设置其分布式Capability能力（仅标准系统以上提供）。
- init提供修改\*.cfg配置文件，为服务提供抑制机制。
服务进程启动&回收能力增强配置，如下：
```
"services" : [{
"name" : "serviceName",
"importance" : 1, // 服务进程提供优先级设置
"cpucore" : [0], // 服务进程提供cpu绑核功能
"critical" : [1, 5, 10], // 服务提供抑制机制
"apl" : "normal", // 系统服务进程设置其分布式Capability能力
"d-caps" : ["OHOS_DMS"], // 系统服务进程设置其分布式Capability能力
"secon" : "u:r:distributedsche:s0" / 服务的SELinux标签， "u:r:distributedsche:s0"为要设置的SELinux标签信息
},
```
- init FD代持（仅标准系统以上提供）
FD代持是按需启动的一个辅助扩展机制，按需启动进程可以保持退出前的fd状态句柄不丢失。按需启动进程退出前可将fd发送给init代持，再次启动后再从init获取fd。
init提供了相关接口供服务调用，服务进程退出前调用接口将fd通过支持IPC通信的socket发送给init代持，待该服务重新启动时，init将持有的该服务相关的fd句柄通过同样的方式返回给服务。相关接口参考：[FD代持接口介绍](#table14737791479)。
- 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执行。触发条件支持&amp;&amp;和||操作，可以根据不同的属性自行组合。
- bootchart 插件
bootchart是一个用于linux启动过程性能分析的开源工具软件，在系统中自动收集CPU占用率、磁盘吞吐率、进程等信息，并以图形方式显示分析结果，可用作指导优化系统启动过程。begetctl命令参考：[begetctl命令说明](#table14737791480)
使用步骤如下所述：
预制条件：
1. 准备bootchart测试环境：linux操作系统下安装python及pycairo
pip install pycairo
2. 在linux解压bootchart-master.tar
tar -zxvf bootchart-master.tar
执行步骤：
1. 启动系统。
2. 执行命令行：begetctl bootchart enable
3. 重启系统。
4. 执行命令行：begetctl bootchart stop
5. 执行命令行：begetctl bootchart disable
6. 在/data/bootchart目录下导出如下文件并存放在bootchart文件夹：<br>
header<br>
proc_diskstats.log<br>
proc_ps.log<br>
proc_stat.log<br>
7. 使用tar -zcvf bootchart.tgz * 命令进行打包（只支持linux版本）并将该打包文件拷贝到linux：bootchart-master目录下。
8. 在bootchart-master目录下运行命令：<br>
python3 pybootchartgui.py -f pdf bootchart.tgz<br>
预期结果：<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;在bootchart-master目录下生成bootchart.pdf。
## 开发指导
1. 配置jobs数组。
init启动引导组件将系统启动分为三个阶段：
- “pre-init”阶段：启动系统服务之前需要先执行的操作，例如挂载文件系统、创建文件夹、修改权限等。
- “init”阶段：系统服务启动阶段。
- “post-init”阶段：系统服务启动完成后还需要执行的操作。
```
"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",
"cmds" : []
}
]
```
**表1** 执行job介绍
| job名 | 说明 |
| :-------- | :-------- |
| pre-init | 最先执行的job，如果开发者的进程在启动之前需要首先执行一些操作（例如创建文件夹），可以把操作放到pre-init中先执行。 |
| init | 中间执行的job，例如服务启动。 |
| post-init | 最后被执行的job，如果开发者的进程在启动完成之后需要有一些处理（如驱动初始化后再挂载设备），可以把这类操作放到该job执行。单个job最多支持30条命令（当前仅支持start/mkdir/chmod/chown/mount/loadcfg），命令名称和后面的参数（参数长度≤128字节）之间有且只能有一个空格。 |
**表2** 命令集说明
| 命令 | 命令格式和示例 | 说明 | 支持系统类型 |
| -------- | -------- | -------- | -------- |
| mkdir | mkdir&nbsp;目标文件夹<br/>如：mkdir&nbsp;/storage/myDirectory | 创建文件夹命令，mkdir和目标文件夹之间有且只能有一个空格。 | small&amp;standard |
| chmod | chmod&nbsp;权限&nbsp;目标<br/>如：chmod&nbsp;0600&nbsp;/storage/myFile.txt<br/>chmod&nbsp;0750&nbsp;/storage/myDir | 修改权限命令，chmod权限目标之间间隔有且仅有一个空格，权限必须为0xxx格式。 | small&amp;standard |
| chown | chown&nbsp;uid&nbsp;gid&nbsp;目标<br/>如：chown&nbsp;900&nbsp;800&nbsp;/storage/myDir<br/>chown&nbsp;100&nbsp;100&nbsp;/storage/myFile.txt | 修改属组命令，chown&nbsp;uid&nbsp;gid目标之间间隔有且仅有一个空格。 | small&amp;standard |
| mount | mount&nbsp;fileSystemType&nbsp;src&nbsp;dst&nbsp;flags&nbsp;data<br/>如：mount&nbsp;vfat&nbsp;/dev/mmcblk0&nbsp;/sdc&nbsp;rw,umask=000<br/>mount&nbsp;jffs2&nbsp;/dev/mtdblock3&nbsp;/storage&nbsp;nosuid | 挂载命令，各参数之间有且仅有一个空格。flags当前仅支持nodev、noexec、nosuid、rdonly，data为可选字段。 | small&amp;standard |
| start | start&nbsp;serviceName<br/>如：start&nbsp;foundation<br/>start&nbsp;shell | 启动服务命令，start后面跟着service名称，该service名称必须能够在services数组中找到。 | small&amp;standard |
| export | export key value<br>如：export TEST /data/test | 设置环境变量命令。后面跟两个参数，第一个参数是环境变量名，第二个参数是环境变量值。| small&amp;standard |
| rm | rm filename<br>如：rm /data/testfile | 删除文件命令。后面跟一个参数，即文件的绝对路径。 | small&amp;standard |
| rmdir | rmdir dirname<br>如：rmdir /data/testdir | 删除目录命令。后面跟一个参数，即目录的绝对路径。 | small&amp;standard | write | write filename value<br>如：write /data/testfile 0 | 写文件命令。后面跟两个参数，第一个参数是文件的绝对路径，第二个参数是要写入文件的字符串。 | small&amp;standard |
| stop | stop servicename<br>如：stop console | 关闭服务命令。后面跟一个参数，即要关闭的服务名。 | small&amp;standard |
| copy | copy oldfile newfile<br>如：copy /data/old /data/new | 拷贝文件命令。后面跟两个参数，第一个参数是原文件绝对路径，第二个参数是新文件绝对路径。 | small&amp;standard |
| reset | reset servicename<br>如：reset console | 重启服务命令。后面跟一个参数，即要重启的服务名。目前reset命令的策略是，如果一个服务没有启动，则该命令会将其拉起，如果一个服务处于运行状态，则该命令会将其关闭后重启。| small&amp;standard |
| reboot | reboot (subsystem)<br>如：reboot updater | 重启系统命令。后面可以跟一个参数，也可以没有参数，当没有参数时执行该命令，将会使设备重启到当前系统，当后面跟参数时，参数应当是子系统的名字，例如,reboot updater，将会重启进入updater子系统。 | small&amp;standard |
| sleep | sleep time<br>如：sleep 5 | 睡眠命令。后面可以跟一个参数，该参数是睡眠时间。 | small&amp;standard |
| domainname | domainname name<br>如：domainname localdomain | 设置域名 | small&amp;standard |
| hostname | hostname name<br>如：hostname localhost | 设置主机名命令。 | small&amp;standard |
| wait | wait PID<br>如：wait pid | 等待命令。| small&amp;standard |
| setrlimit | setrlimit resource curValue maxValue<br>如：| 设定资源使用限制命令。 | small&amp;standard |
| write | write path content<br>如：write /proc/sys/kernel/sysrq 0 | 写文件命令。 | small&amp;standard |
| exec | exec 可执行文件路径 可执行文件传的参数<br>如：exec /system/bin/udevadm trigger | 系统调用命令。 | small&amp;standard |
| mknode |mknod name { b \| c } Major Minor<br>如mknod path b 0644 1 9| 建立一个目录项和一个特殊文件的对应索引节点。 参考mknod命令 |standard |
| makedev | makedev major minor<br>如：makedev -v update | 创建静态的设备节点命令，通常位于/dev目录下。| standard |
| symlink | symlink path1 path2<br>如：symlink /proc/self/fd/0 /dev/stdin | 符号链接命令。 | standard |
| trigger | trigger jobName<br>如：trigger early-fs | 触发job执行的命令。 | standard |
| insmod | insmod ko文件<br>如：insmod xxx.ko| 内核模块文件载入命令。 | standard |
| setparam | setparam paramname paramvalue<br>如：setparam sys.usb.config hdc| 设置系统参数。| standard |
| load_persist_params | load persist params<br>如：load_persist_params&nbsp;| 加载persist参数。load_persist_params命令后有且仅有一个空格 | standard |
| load_param | load params<br>如：load_param /data/test.normal.para| 将文件里的param加载到内存。| standard |
| load_access_token_id | 如：load_access_token_id&nbsp;| 将access token信息写入data/service/el0/access_token/nativetoken.json文件，load_access_token_id后有且只有一个空格。| standard |
| ifup | ifup 激活网络接口<br>如：ifup eth0 | 激活指定的网络接口。| standard |
| mount_fstab | mount_fstab fstab.test<br>如：mount_fstab /vendor/etc/fstab.test| 按照fstab挂载分区的命令。 | standard |
| umount_fstab | umount_fstab fstab.test<br>如：umount_fstab /vendor/etc/fstab.test | 按照fstab卸载分区的命令。 | standard |
| restorecon | restorecon file or dir<br>如：restorecon /file | 重新加载selinux 的context。 | standard |
| stopAllServices | stopAllServices [bool]<br>如：stopAllServices false 或 stopAllServices | 停止所有服务。 | standard |
| umount |umount path<br>如：umount /vendor | 卸载已经挂载的硬件设备 。 | standard |
| sync | 如：sync&nbsp; | 同步写入数据到磁盘。sync后有且仅有一个空格。| standard |
| timer_start | timer_start serviceName<br>如：timer_start console | 启动服务计时器。 | standard |
| timer_stop | timer_stop serviceName<br>如：timer_stop console | 停止服务计时器。 | standard |
| init_global_key | init_global_key path 如：init_global_key /data | data分区文件加密key初始化。| standard |
| init_main_user | 如：init_main_user| 主用户目录加密。| standard |
| mkswap | mkswap file<br>如：mkswap /swapfile1 | 在一个文件或者设备上建立交换分区。 | standard |
| swapon | swapon file <br>如：swapon /swapfile1| 激活交换空间 | standard |
| loadcfg | loadcfg&nbsp;filePath<br/>如：loadcfg&nbsp;/patch/fstab.cfg | 加载其他cfg文件命令。后面跟着的目标文件大小不得超过50KB，且目前仅支持加载/patch/fstab.cfg，其他文件路径和文件名均不支持。/patch/fstab.cfg文件的每一行都是一条命令，命令类型和格式必须符合本表格描述，命令条数不得超过20条。 | small |
2. 配置services数组，service集合（数组形式），包含了init进程需要启动的所有系统服务。
```
"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字段说明<a name="table14737791471"></a>
| 字段名 | 字段说明 | 字段解释 | 支持系统类型 |
| ---------- |-------- | --------| --------|
| name | 当前服务的服务名。 | 类型：字符串； 服务名非空且长度<=32字节。| small&amp;standard |
| path | 当前服务的可执行文件全路径和参数，数组形式。 | 确保第一个数组元素为可执行文件路径、数组元素个数<=20。 <br> 每个元素为字符串形式以及每个字符串长度<=64字节。| small&amp;standard |
| uid | 当前服务进程的uid值。 | 类型：int | small&amp;standard |
| gid | 当前服务进程的gid值。 | 类型：int | small&amp;standard |
| once | 当前服务进程是否为一次性进程。 | 1：一次性进程，当该进程退出时，init不会重新启动该服务进程。 <br> 0 : 常驻进程，当该进程退出时，init收到SIGCHLD信号并重新启动该服务进程。 | small&amp;standard |
| importance | 当前服务优先级 | 标准系统中:<br> &emsp; &emsp;服务优先级取值范围 [-20， 19]，超出为无效设置。<br> 小型系统中：<br> &emsp; &emsp;0 : 非重要进程 <br> &emsp; &emsp;非0 : 重要进程 | small&amp;standard |
| caps | 当前服务所需的capability值，根据安全子系统已支持的capability，评估所需的capability，遵循最小权限原则配置。| 类型：数字或者字符串数组，在配置数字时，按linux标准的capability进行配置。字符串时，使用标准定义的宏的名字进行配置。 | small&amp;standard |
| critical | 为服务提供抑制机制，服务在配置时间 T 内，频繁重启次数超过设置次数 N 重启系统。 | 标准系统中<br> &emsp; &emsp;类型：int型数组，如："critical" : [M, N, T]<br> &emsp; &emsp; M：使能标志位（0：不使能；1：使能）， N：频繁拉起服务次数， T：时间(单位：秒)。<br> &emsp; &emsp; M > 0; N > 0 <br> 小型系统中 & 标准系统中：<br> &emsp; &emsp;类型：int，如："critical" : M<br> &emsp; &emsp; M：使能标志位（0：不使能；1：使能）<br> &emsp; &emsp；默认拉起服务次数：4次， 时间：20秒。 | small&amp;standard |
| cpucore | 服务需要的绑定的cpu核心数 | 类型：int型数组， 如"cpucore" : [N1, N2, ...], N1， N2均为需要绑定的cpu核索引<br> 如单核设备 cpucore : [0] | small&amp;standard |
| d-caps | 服务分布式能力（仅标准系统以上提供）。| 类型：字符串数组， 如 "d-caps" : ["OHOS_DMS"] | standard |
| apl | 服务能力特权级别（仅标准系统以上提供）。 | 类型：字符串， 如 "apl" : "system_core"。<br> 目前支持"system_core"（默认值）, "normal", "system_basic"。 | standard |
| start-mode | 服务的启动模式（仅标准系统以上提供）。 | 类型：字符串， 如 "start-mode" : "condition"。<br>目前支持"boot", "normal", "condition"。具体说明参考：[init服务启动控制](#section56901555918) | standard |
| jobs | 当前服务在不同阶段可以执行的job。 | 具体说明参考：[init服务并行控制](#section56901555919) | small&amp;standard |
| ondemand | 按需启动服务的标志。 | 类型：bool，如"ondemand" : true，小型系统只在Linux内核上支持。具体说明参考：[init服务按需启动](#section56901555920)| small&amp;standard |
| disable | 预留字段，无实际意义。 | | small&amp;standard |
3. 服务中socket配置和按需启动。
服务中支持配置 "socket" 属性，该属性以一个JSON对象的格式配置。配置有 "socket" 属性的服务，init将会为其创建socket，以是否为按需启动服务来区分其创建的时机。
- 按需启动的服务，init会在解析到该服务时，根据解析到的socket配置进行创建。
- 正常启动的服务，init会在拉起该服务时，执行服务可执行文件之前创建其配置的socket。
无论服务是否按需启动，其真正被拉起后，都需要通过特定接口获取init为其创建的socket句柄，进而接手该socket的管理，成为服务自有的socket。
除以上socket的配置和创建流程，对于按需启动的服务，init还有不同行为。当init在创建根据服务的socket配置创建完socket后，将会判断服务的ondemand属性是否为true（按需启动服务），若是则会调用接口对socket进行轮询监听，直到socket有消息上报，此时将停止监听并拉起对应服务，由服务接管该socket并处理消息。
下面以ueventd服务为例介绍服务中socket和按需启动的配置以及各字段的含义。
```
"services" : [{
"name" : "ueventd",
"path" : ["/system/bin/ueventd"],
"socket" : [{
"name" : "ueventd",
"family" : "AF_NETLINK",
"type" : "SOCK_DGRAM",
"protocol" : "NETLINK_KOBJECT_UEVENT",
"permissions" : "0660",
"uid" : "system",
"gid" : "system",
"option" : [
"SOCKET_OPTION_PASSCRED",
"SOCKET_OPTION_RCVBUFFORCE",
"SOCK_CLOEXEC",
"SOCK_NONBLOCK"
]
}],
"critical" : [ 0, 5, 15],
"ondemand" : true,
"start-mode" : "condition"
}]
```
**表4** socket字段说明
| 字段名 | 说明 |
| -------- | -------- |
| name | 当前socket的命名，不要求必须与服务同名，与服务名同样须满足非空且长度<=32字节。|
| family | socket所属的地址族，目前支持的为服务创建的socket有AF_UNIX和AF_NETLINK族。|
| type | socket的类型，目前支持的类型有基于连接的SOCK_SEQPACKET和SOCK_STREAM，还有基于UDP无连接的SOCK_DGRAM。|
| protocol | socket通信遵循的协议类型，在无特殊需求的情况下，该值可配置为default缺省值，因为socket接口会自动根据socket地址族和类型选择合适的协议。此处除了default，并且支持NETLINK_KOBJECT_UEVENT协议类型。|
| permissions | socket节点文件的权限。此项配置仅对如AF_UNIX地址族等有实体节点文件的socket类型有效。|
| uid | socket节点文件的用户ID。此项配置仅对如AF_UNIX地址族等有实体节点文件的socket类型有效。|
| gid | socket节点文件的组ID。此项配置仅对如AF_UNIX地址族等有实体节点文件的socket类型有效。|
| option | socket的可选配置。在调用setsockopt接口时传入设置，目前支持的option选项有SOCKET_OPTION_PASSCRED、SOCKET_OPTION_RCVBUFFORCE、SOCK_CLOEXEC和SOCK_NONBLOCK。|
**表5** FD代持接口介绍<a name="table14737791479"></a>
| 函数名 | 函数解释 | 参数解释 |
| ---------- | ---------- |--------|
| int *ServiceGetFd(const char *serviceName, size_t *outfdCount) | 获取init代持的fd | 返回值：成功返回fd数组指针，失败返回NULL。备注：需手动释放<br>参数：<br> serviceName: 服务名<br>outfdCount: 返回的fd数组长度 |
| int ServiceSaveFd(const char *serviceName, int *fds, int fdCount) | 请求init代持fd | 返回值：成功返回0，失败返回-1 <br> 参数：<br> serviceName: 服务名 <br> fds: 需要init代持的fd数组指针<br>fdCount: fd数组长度
| int ServiceSaveFdWithPoll(const char *serviceName, int *fds, int fdCount) | 使用poll方式，请求fd代持 | 返回值：成功返回0，失败返回-1 <br> 参数：<br> serviceName: 服务名 <br> fds: fd代持数组指针 <br> fdCount 数组长度
**表6** 服务控制接口介绍
| 函数名 | 函数解释 | 参数解释 |
| :---------- | :---------- |:--------|
| int ServiceControlWithExtra(const char *serviceName, int action, const char *extArgv[], int extArgc) | 配置服务参数 | 返回值：成功返回0，失败返回-1 <br> 参数: <br> serviceName: 服务名 <br> action: 服务行为（"start", "stop", "restart"） <br> extArgv: 参数数组 <br> extArgc: 参数个数 |
| int ServiceControl(const char *serviceName, int action) | 控制服务行为 | 返回值：成功返回0，失败返回-1 <br> 参数：<br> serviceName: 服务名 <br> action: 服务行为（"start"， "stop", "restart") |
| int ServiceWaitForStatus(const char *serviceName, ServiceStatus status, int waitTimeout) | 等待服务状态 | 返回值：成功返回0， 失败返回-1。<br> 参数：<br>serviceName: 服务名 <br> status: 返回服务状态 <br> 超时时间 |
| int ServiceSetReady(const char *serviceName) | 设置服务准备 | 返回值：成功返回0，失败返回-1 <br> 参数：<br> serviceName: 服务名 |
| int StartServiceByTimer(const char *serviceName, uint64_t timeout) | 定时启动服务 | 返回值：成功返回0，失败返回-1 <br> 参数: <br> serviceName: 服务名 <br> timeout: 超时时间 |
| int StopServiceTimer(const char *serviceName) | 停止服务计时器 | 返回值：成功返回0，失败返回-1 <br> 参数：<br> serviceName: 服务名 |
**表7** begetctl 命令说明<a name="table14737791480"></a>
| 命令 | 命令格式和示例 | 说明 |
| :---------- | :---------- |:--------|
| init group test [stage] | init group test | stage参见ServiceStatus。 |
| param ls [-r] [name] | 显示系统参数，例如：<br>查看usb系统参数：begetctl param ls persist.sys.usb | 无 |
| param get [name] | 获取系统参数信息，例如：<br>begetctl param get 或 param get | 无 |
| param set name value| 设置系统参数，例如：<br>begetctl param set ohos.servicectrl.display 1 或 param set ohos.servicectrl.display 1| 无 |
| param wait name [value] [timeout] | 等待系统参数，例如：<br>begetctl param wait persist.sys.usb.config hdc 或 param wait persist.sys.usb.config hdc | timeout默认值：30 |
| param dump [verbose] | dump 系统参数信息，例如：<br>begetctl param dump 或 param dump| 无 |
| param shell [name] | 进入Parameter shell，例如：<br>begetctl param shell 或 param shell| 无 |
| timer_stop servicename | 停止服务计时器，例如：<br>begetctl timer_stop appspawn | servicename长度不超过96字符 |
| timer_start servicename timeout | 启动服务计时器，例如：<br>begetctl timer_start appspawn | servicename长度不超过96；timeout默认值：10 |
| start_service servicename | 启动服务，例如：<br>begetctl start_service appspawn 或 start_service appspawn | 无 |
| stop_service servicename | 停止服务，例如：<br>begetctl stop_service appspawn 或 stop_service appspawn | 无 |
| service_control start servicename | 启动服务，例如：<br>begetctl service_control start appspawn 或 service_control start appspawn | 无 |
| service_control stop servicename | 停止服务，例如：<br>begetctl service_control stop appspawn 或 service_control stop appspawn | 无 |
| misc_daemon --write_logo xxx.rgb | 写入开机logo，例如：<br>begetctl misc_daemon --write_logo logo.rgb 或 misc_daemon --write_logo logo.rgb| rgb文件最大不超过1024*2038，仅支持hi3516dv300 |
| reboot | 重启系统，例如：<br>begetctl reboot 或 reboot|无 |
| reboot shutdown | 关闭系统，例如：<br>begetctl reboot shutdown 或 reboot shutdown |无 |
| reboot suspend | 暂停系统，例如：<br>begetctl reboot suspend 或 reboot suspend | 无 |
| reboot updater | 重新启动并进入updater，例如：<br>begetctl reboot updater 或 reboot updater | 无 |
| reboot updater[:options] | 重新启动并进入updater，例如：<br>begetctl reboot updater 或 reboot updater | 无 |
| reboot flashd | 重新启动并进入flashd，例如：<br>begetctl reboot flashd 或 reboot flashd | 无 |
| reboot flashd[:options] | 重新启动并进入flashd，例如：<br>begetctl reboot flashd 或 reboot flashd | 无 |
| reboot charging | 重新启动并进入charging，例如：<br>begetctl reboot charging 或 reboot charging| 无 |
| reboot loader | 重新启动并进入烧写模式，例如：<br>begetctl reboot loader 或 reboot loader | 无 |
| bootchart stop | 停止图形分析，例如：<br>begetctl bootchart stop | 仅支持rk3568|
| bootchart start | 开始图形分析，例如：<br>begetctl bootchart start | 无 |
| bootchart disable | 图形分析不使能，例如：<br>begetctl bootchart disable | 无 |
| bootchart enable | 图形分析使能，例如：<br>begetctl bootchart enable | 无 |
## 开发实例
init启动引导程序，此处以要新增一个名为MySystemApp的系统服务为例进行说明，使用如下配置：
```
{
"jobs" : [{
"name" : "pre-init",
"cmds" : [
"mkdir /storage/MyDir", // MySystemApp服务启动之前需要先创建文件夹，因此放在 “pre-init”中进行
"chmod 0600 /storage/MyDir", // MySystemApp服务要求该文件夹只有本用户和属组才可读写，因此需要修改权限
"chown 10 10 /storage/MyDir"
]
}, {
"name" : "init",
"cmds" : [
"start MySystemApp" // 在init中启动该系统服务
]
}, {
"name" : "post-init",
"cmds" : [] // MySystemApp系统服务启动后无需进行其他操作，因此不用配置“post-init”
}
],
"services" : [{
"name" : "MySystemApp", // 系统服务名称
"path" : ["/bin/MySystemAppExe", "param1", "param2", "param3"], // MySystemApp系统服务的可执行文件路径为"/bin/MySystemAppExe"，其启动需要传入三个参数，分别是"param1"、"param2"和"param3
"uid" : 20, // MySystemApp系统服务的uid是20
"gid" : 20, // MySystemApp系统服务的gid是20
"once" : 0, // MySystemApp系统服务的非一次性进程，即如果MySystemApp系统服务因任何原因退出，init进程需要将其重新拉起
"importance" : 0, // MySystemApp系统服务不是关键系统进程，即如果MySystemApp系统服务因任何原因退出，init进程无需重启单板
"caps" : [], // MySystemApp系统服务不需要任何capability权限（即MySystemApp系统服务不涉及与capability相关的操作）
"start-mode" : "condition",
"critical": [1, 2, 10], //MySystemApp系统服务的critical配置，需传入三个参数， 分别为使能：1， 执行次数：2， 执行时间：10
"cpucore" : [0, 1], // 设备为双核， 且都绑定cpu
"apl" : "system_core",
"d-caps" : ["OHOS_DMS"],
"jobs" : {
"on-boot" : "boot",
"on-start" : "services:MySystemApp_start",
"on-stop" : "services:MySystemApp_stop",
"on-restart" : "services:MySystemApp_restart"
}
}
]
}
```
完成配置后，编译出包烧写单板：
1. 启动后使用task -a（liteos-a版本）或ps命令（linux版本）查看是否MySystemApp系统服务进程已启动。
2. 使用kill命令将上述新增的MySystemApp进程杀死，观察该进程是否会被重新拉起（此处应该为重新拉起）。
3. 使用kill命令将上述新增的MySystemApp进程杀死，观察是否会导致单板重启（此处应该为不重启）。
## 常见问题
### 服务不存在
**现象描述**
内核Log打印 "Failed get servName"。
**原因分析**
kernel log的输出，都是由init打印。在init 中查找对应的代码位置。发现是服务不存在。
**解决方法**
1. 确认服务是否在cfg中正确配置。
2. 服务的cfg文件是否正常加载。
3. cfg文件格式是否正确。
### 请求其他服务代持fd，init有报错
**现象描述**
内核Log打印 "Service ' xxx '(pid = xxx) is not valid or request with unexpected process(pid = xxx)"。
**原因分析**
kernel log的输出，都是由init 打印。在init中查找对应的代码位置。发现是其他服务代持fd。
**解决方法**
只支持代持本服务的fd，不允许让其他服务代持fd。
### 服务没有配置 ondemand 选项
**现象描述**
内核Log打印 "service : %s had started already"。
**原因分析**
kernel log 的输出，都是由init 打印。在init 中查找对应的代码位置。发现是服务没有配置ondemand。
**解决方法**
服务对应的.cfg文件正确配置如： "ondemand" : true。
\ No newline at end of file
- **[插件](subsys-boot-init-plugin.md)**
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或