Job Management

Overview

Function

A job is a set of commands in the .cfg file of the init module. A maximum of 4096 jobs can be added. Jobs can be configured in the .cfg file. Generally, jobs are executed during initialization to serve the normal startup of services or the initialization of specific basic functions.

Basic Concepts

A job can be configured in the init.cfg file or the custom .cfg file of the module. The parser of the init process aggregates commands of the jobs with the same name into one job. For jobs with the same name, the init process only ensures that the commands in the init.cfg file are executed in preference. It does not guarantee the execution sequence of commands in other .cfg files.

• Basic job

  A job executed in a fixed phase during init process startup, for example, pre-init, init, or post-init.

  • pre-init: pre-initialization phase. Key services on which other services depend, such as ueventd, watchdog, and hilogd, are started in this phase. The mounting of data partitions is also done in this phase.
  • init: main phase of the initialization process. In this phase, a large number of commands are executed, and services in the boot group (first group) are started concurrently by the init group. Some important services related to system functions are also started in this phase.
  • post-init: post-initialization phase. In this phase, the trigger command is used to invoke the execution of other phases, which can be regarded as independent phases, or the post-init phase as a whole. In this phase, a large number of commands are executed, and the normal group (the second group) is started by the init group. Most services configured in the .cfg files are started in this phase.

• Custom job (for standard system or higher)

  A job triggered based on specific rules. You can add commands to the job as required and run the trigger command to invoke the execution of commands in the job.

• Conditional job (for standard system or higher)

  A job triggered based on specific conditions. You can add conditions to a job so that the job is executed when the conditions are met.

  A condition is a combination of system parameter values. It supports operations such as && and || as well as matching of any parameter values by using the wildcard character (*).

  Generally, you can configure a condition in the format shown below:

  "condition": "sys.usb.config = none && sys.usb.configfs = 0"
  

  If you need to enable parameter checking in the boot phase, configure the condition as follows:

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

  When defining commands for a job, you can add attributes in the format of param:xxx to form different commands.

Constraints

With the system parameter module, the standard system is able to support basic, conditional, and custom jobs. The small system supports only basic jobs.

How to Develop

Use Cases

A job is a command set, where you can manage the commands to be executed. A maximum of 4096 commands can be added to a command set. During the init startup process, the execution of jobs helps ensure normal running of services.

Parameter Description

Table 1 Command set description

Available APIs

Job management is a part of the init startup process. It is a process-based function that completely serves the init startup process. It does not provide any functional APIs for other modules. It works in a way similar to command group management and does not provide help for other types of management. The following describes the job management APIs.

Table 2 Description of job parsing APIs

Table 3 Description of the job triggering APIs

Example

The following is the template for configuring jobs in the .cfg file. You can use it to verify the job management function.

{
    "jobs" : [{     // Basic job
            "name" : "stage1",
            "cmds" : [
                "start service1",
                "mkdir dir1"
            ]
        }, {        // Conditional job
            "name" : "param:test.name1=0",
            "condition" : "test.name1=0",
            "cmds" : [
                "chmod 0755 dir1",
                "chown root root dir1"
            ]
        }, {        // Custom job
            "name" : "param:test.name2=*",
            "condition" : "test.name2=*",
            "cmds" : [
                "chmod 0644 dir1",
                "chown system system dir1"
            ]
        }
    ]
}

The differences in job configuration are described as follows:

1. name and cmds are mandatory for a job, and cmds must contain commands supported by the system.

2. condition is an optional attribute of a job. It indicates that the job is triggered only when the specified condition is met; that is, the job will not be invoked in a specific phase by the code or the trigger command.

3. The job name must comply with the specified rules. For a job whose condition is a system parameter, its name is prefixed with param:.

4. Commands in a renamed job can be executed only after being triggered by the trigger command in other executable job command groups. By default, the trigger command is executed in the post-init phase.

5. An existing job name can be used in different files. Jobs with the same name are regarded as the same job. When jobs with the same name are executed, the commands in these jobs are executed together.

6. For a conditional job, a condition is usually a system parameter. You can set a specific value so that the job is triggered when the condition is met. You can also set the value to an asterisk (*) so that the job is triggered whenever the condition is met, regardless of the parameter value.

7. For the small system, the commands in a job cannot be triggered by the trigger command in the post-init phase.