jobs管理

概述

功能简介

jobs是init组件下cfg文件中的一组命令构成的集合, 最多添加4096个job。 jobs可以在 cfg 文件中配置，通常在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",
  

  如果特殊情况需要在boot阶段对参数做检查可按下面示例配置：

  "condition" : "boot && const.debuggable=1",
  

  并且jobs在定义命令时，按照下面的规则"param:xxx"命名, 可以根据不同的属性自行组合。

约束与限制

在标准系统下有系统参数模块的支持，支持基本jobs、条件jobs、自定义jobs。在小型系统中只支持基本jobs。

开发指导

场景介绍

job就是命令集合，jobs管理就是对要执行的一组命令集合进行管理， 一组命令集合最多添加4096个命令。在init启动过程中，jobs的执行为服务的正常运行提供支持。

参数说明

表1 命令集说明

接口说明

jobs管理属于init启动过程中的一环，是一个流程化的功能，是完全服务于init启动过程的，并不对其他组件提供任何功能接口，其运行逻辑契合cfg中命令组的管理，无法对其他类型管理提供帮助。下述主要介绍其在init当中的调用逻辑。

表2 job解析接口说明

表3 job触发接口说明

开发实例

下述为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命令。