1# startup常见问题 2 3## 启动恢复常见问题 4 5### 设备启动过程中打印“parse failed!”错误后停止启动 6 7**现象描述** 8 9设备启动过程中，打印日志“[Init] InitReadCfg, parse failed! please check file /etc/init.cfg format.”错误，启动过程停止，如下图所示： 10 11 **图1** 运行报错图 12 13  14 15**可能原因** 16 17init.cfg文件内容不符合JSON语法格式。 18 19**解决办法** 20 21排查init.cfg文件，格式符合JSON格式要求。 22 23 24### 设备开机后，反复重启。 25 26**现象描述** 27 28设备启动过程中反复重启。 29 30**可能原因** 31 32init服务中定义“importance”的属性（详见[参数说明](../subsystems/subsys-boot-init-service.md#参数说明)描述）。 33 34- 属性值为0时，表示当前服务进程退出，设备不重启。 35 36- 属性值为1时，表示当前服务进程退出，设备重启。 37 38**解决办法** 39 401. 通过日志确认崩溃或报错退出的服务，并解决其崩溃/报错的问题，重新烧写镜像即可。 41 422. 将崩溃/报错退出的服务的“importance”属性改为0，重新烧写镜像，设备不重启。 43 44 45### 调用SetParameter/GetParameter返回失败 46 47**现象描述** 48 49在参数正确的情况下，调用SetParameter/GetParameter返回失败。 50 51**出现问题系统类型** 52 53liteos-a 54 55**可能原因** 56 57程序有对SetParameter/GetParameter这两个接口做权限校验，因此在各参数正确的情况下，调用SetParameter/GetParameter返回操作失败，是调用者的uid大于1000，没有调用权限。 58 59**解决办法** 60 61无需处理。 62 63### ueventd服务启动后报获取socket失败，尝试创建 64 65**现象描述** 66 67ueventd服务启动后，打印日志 “Failed to get uevent socket, try to create”日志，并且有如下图所示错误日志： 68 69 **图2** ueventd获取socket失败 70 71  72 73**可能原因** 74 75由于ueventd服务是按需启动的服务，其设备启动后，首先从环境变量中拿到init为其创建的socket的fd。根据上述报错打印可知，是获取环境变量的值失败，这种情况可能是： 761. cfg文件中的ueventd服务没有配置socket，导致init并没有为其创建socket，也就没有相应的环境变量能够让其获取。 772. cfg文件中的ueventd服务已经配置了socket，那可能是在另外一个cfg文件中重复配置了ueventd服务，并且其中没有配置socket。 78 79**解决办法** 80 811. cfg文件没有配置socket，需要在cfg文件中对ueventd服务进行socket配置，具体可参看init.cfg中ueventd[服务的socket配置](../subsystems/subsys-boot-init-service.md#参数说明)。 822. 重复配置socket，需要查看所有cfg文件找到重复配置的ueventd服务，并将其删除，保留一个有效的ueventd服务配置。 83 84### ueventd服务轮询socket超时，并自动退出 85 86**现象描述** 87 88ueventd服务启动一段时间后，出现打印日志 “poll ueventd socket timeout, ueventd exit” 并自动退出。 89 90**可能原因** 91 92由于ueventd服务是按需启动的服务，其行为是当有uevent事件上报时，init监听到socket消息，会将ueventd服务拉起使其处理相应的socket消息，ueventd服务处理完现有的socket消息后，会自己再轮询对应socket句柄30秒，若30秒内又有新消息上报，则继续处理，待处理结束后再次计时轮询30秒；若超过30秒都没有新消息上报，ueventd服务将会退出，并将socket交还给init轮询，此时就会出现日志中的打印，因此这是一个正常的行为逻辑。 93 94**解决办法** 95 96正常行为，无需解决。 97 98### 配置了ondemand属性的服务无法被正确解析启动 99 100**现象描述** 101 102符合JSON格式的服务配置无法被正确解析，打印日志 “Service is invalid which has both critical and ondemand attribute”，启动该服务时提示“Cannot find service”. 103 104**可能原因** 105 106ondemand属性默认是按需启动的，ondemand和critical属性互斥，两者同时配置，服务不能被正确解析 。 107 108**解决办法** 109 1101. 服务不按需启动， 不需要配置ondemand属性。 1112. 服务按需启动， critical是常驻进程配置， 配置ondemand属性后，不需要再配置critical属性， 或者配置critical属性不使能。 112 113### 配置ondemand属性的服务不受并行启动控制 114 115**现象描述** 116 117配置ondemand属性的服务并没有在并行启动阶段被拉起，start-mode设置无效 118 119**可能原因** 120 121ondemand属性属于按需启动配置， 服务未能满足启动条件，因此未能成功拉起服务， 属于正常现象。 122 123**解决办法** 124 125并行启动的服务不配置ondemand属性。 126 127### SA按需启动服务无法按需拉起 128 129**现象描述** 130 131SA服务配置为按需启动的情况，在SA客户端发送请求后，samgr并没有动态拉起SA服务。 132 133**可能原因** 134 135在SA服务实现按需启动初期，使用统一接口SystemAbilityManager::CheckSystemAbility(int32_t systemAbilityId)，后续为了将按需启动的SA服务区分开来，新增samgr提供的动态加载接口LoadSystemAbility(int32_t systemAbilityId, const sptr& callback)，原接口不适配按需启动的SA服务，故导致SA服务未能按需拉起。 136 137**解决办法** 138 139在按需启动的SA服务中使用samgr提供的动态加载接口LoadSystemAbility(int32_t systemAbilityId, const sptr& callback)。 140 141### caps配置不合理 142 143**现象描述** 144 145caps 配置错误，会导致配置失效，报错如下： 146 ``` 1474.619955] [pid=1 0][Init][ERROR][init_capability.c:119]service=multimodalinput not support caps = CAP_DC_OVERRIDE caps 41 148[ 4.620014] [pid=1 0][Init][ERROR][init_service_manager.c:818]GetServiceSecon secon section not found, skip 149[ 4.620216] [pid=1 0][Init][ERROR][init_service_manager.c:818]GetServiceSecon secon section not found, skip 150[ 4.620608] [pid=1 0][Init][ERROR][init_capability.c:119]service=mmi_uinput_service not support caps = CAP_DC_OVERRIDE caps 41 151``` 152**可能原因** 153 1541. 内核不支持。 1552. cfg文件中配置错误。 156 157**出现问题版本** 158 159OpenHarmony-3.0-LTS 160 161**解决办法** 162 1631. 内核不支持， 不需要配置caps。 1642. 内核支持，cfg文件中caps配置不正确，导致在init中解析的时候，解析失败，参考base/startup/init/services/init/init_capability.c中，capStrCapNum数据结构的定义，正确配置caps。 165 166### 打开沙盒功能 167 168**现象描述** 169 170通过hdc shell param get const.sandbox查看该parameter的值不是enable。 171 172**可能原因** 173 174无。 175 176**解决方法** 177 178在base/startup/init/services/etc/param/ohos.para中配置const.sandbox=enable。具体参考[沙盒指导](../subsystems/subsys-boot-init-sandbox.md) 179 180### 查看服务中沙盒的挂载状态 181 182**现象描述** 183 184无。 185 186**可能原因** 187 188无。 189 190**解决方法** 191 192设备进入hdc shell下， 执行sandbox -s service_name命令，模拟当前服务进入沙盒场景， 通过 ls 等shell命令查看当前服务沙盒目录。具体参考[沙盒命令](../subsystems/subsys-boot-init-plugin.md) 193 194### Bootevent部分事件的ready阶段的时间戳为0 195 196**现象描述** 197 198Bootevent手动模式下，开机完成之后在执行dump_service all bootevent命令后有部分事件的ready阶段的时间戳为0。 199 200**可能原因** 201 2021. 服务没有发送bootevent事件。 2032. 服务发送bootevent事件， 但是没有相关权限。 204 205**解决方法** 206 2071. 服务配置了bootevent，但是没有发送该bootevent事件，请相关服务在代码中发送该bootevent事件。 2082. 在代码中已经执行到设置bootevent的操作，但是ready的状态就是为零，此时请检查服务是否有设置bootevent参数的权限。 209 210### A/B分区启动过程因只烧写原始分区导致的无法启动 211 212**现象描述** 213 214烧写完成后系统无法正常启动，并且可以在串口日志中找到类似如下打印： 215 216``` 217wait for file:/dev/block/platform/fe310000.sdhci/by-name/system_b failed after 5 second. 218Mount /dev/block/platform/fe310000.sdhci/by-name/system_b to /usr failed 2 219``` 220 221**可能原因** 222 223当前系统已经支持了A/B分区启动，根据日志可知本次启动尝试挂载了带"_b"后缀的system分区，即本次启动从B分区启动，但是并没有找到设备，导致挂载失败。这种情况是由于当前misc分区中的active slot值被设置为了2（B分区），但是并没有烧写对应B分区导致的。 224 225**解决方法** 226 2271. 可以清空misc分区（使用空misc镜像烧写对应分区），将其中的active slot值擦除，再次启动即可从默认分区启动。 2282. 使用配置了B分区的分区表将system_b和vendor_b镜像烧写到开发板中，再次启动即可从对应B分区正常启动。 229 230## Appspawn应用孵化常见问题 231 232### 设备启动中，appspawn启动失败 233 234**现象描述** 235 236设备启动过程中，设备停止开机动画中， 进入appspawn失败。 237 238**可能原因** 239 2401. 开机动画未能正常退出。 2412. 拉起系统应用失败， 导致appspawn启动失败。 242 243**解决办法** 244 245需要通过日志确认崩溃或报错退出的服务，并解决其崩溃/报错的问题，然后重新烧写镜像即可。 246 247### 冷启动命令启动应用失败 248 249**现象描述** 250 251通过冷启动命令拉起应用失败。 252 ``` 253 aa start -d 12345 -a $name -b $package -C 254 ``` 255 256**可能原因** 257 2581. 冷启动状态未打开。 2592. 冷启动命令参数输入错误。 2603. socket请求超时。 2614. selinux打开。 262 263**解决办法** 264 2651. 冷启动不使能， 通过param get startup.appspawn.cold.boot命令查看状态，如果冷启动状态是0, 通过param set startup.appspawn.cold.boot 1 命令打开冷启动状态。 2662. 冷启动命令参数不正确， 查看并确认冷启动参数。 2673. 设置超时时间>3秒，执行 param set persist.appspawn.client.timeout 5 命令。 2684. 关闭selinux, 执行 setenforce 0 命令。 269 270### 应用沙盒创建失败 271 272**现象描述** 273 274com.ohos.systemui应用启动失败、OpenHarmony开机动画退出失败、计算器应用无法使用、字体不能正常显示等。日志报错： 275 - bind mount `<src-path>` to `<sandbox-path>` failed errno `<errorCode>`。 276 - private mount to `<sandbox-path>` failed errno `<errorCode>`。 277 - symlink failed, `<link-name>`, errno is `<errorCode>`。 278 279**可能原因** 280 2811. 沙盒流程创建失败。 2822. com.ohos.systemui沙盒创建失败。 2833. 沙盒应用依赖的文件配置失败。 284 285**解决办法** 286 2871. 查看hilog日志中，排查相关hilog报错信息，针对报错修改对应的JSON文件。 2882. 查看对应应用的pid情况，排查沙盒建立过程的代码逻辑，以及相应的JSON配置的正确性。 289 290具体参考[应用沙盒开发步骤](../subsystems/subsys-boot-appspawn.md#开发步骤)
