JavaScript promise rejection: Loading CSS chunk katex failed. (error: https://free-git.org/assets/css/katex.fb6ef55c.css). Open browser console to see more details.
Go to file
chengjinsong 75aa87f19e codex
Signed-off-by: chengjinsong <chengjinsong2@huawei.com>
2022-08-12 11:57:20 +08:00
device_info modify samgr 2022-08-02 11:17:46 +08:00
initsync Merge branch 'master' of gitee.com:openharmony/startup_init_lite into init 2022-07-20 09:13:03 +00:00
interfaces codex 2022-08-12 11:57:20 +08:00
scripts 解决编译随机失败 2022-06-30 19:02:22 +08:00
services codex 2022-08-12 11:57:20 +08:00
test Merge branch 'master' of gitee.com:openharmony/startup_init_lite into initmusl1 2022-08-10 09:52:49 +00:00
ueventd Merge branch 'master' of gitee.com:openharmony/startup_init_lite into initmusl1 2022-08-10 09:52:49 +00:00
watchdog support build musl with param base 2022-08-08 08:54:45 +08:00
begetd.gni Merge branch 'master' of gitee.com:openharmony/startup_init_lite into initmusl1 2022-08-10 09:52:49 +00:00
bundle.json modify samgr 2022-08-02 11:17:46 +08:00
LICENSE update openharmony 1.0.1 2021-03-11 18:45:09 +08:00
OAT.xml fix invalid type in OAT.xml and other typos 2022-06-18 22:57:25 +08:00
README_zh.md init 2022-07-05 21:14:12 +08:00
README.md init 2022-07-05 21:14:12 +08:00

init

Introduction

The init module starts system service processes from the time the kernel loads the first user-space process to the time the first application is started. In addition to loading key system processes, the module needs to configure their permissions during the startup and keep the specified process alive after sub-processes are started. If a process exits abnormally, the module needs to restart it, and to perform system reset for a special process.

Directory Structure

base/startup/init/             # init module
├── LICENSE
└── services
    ├── include                  # Header files for the init module
    ├── src                      # Source files for the init module
    └── test                     # Source files of the test cases for the init module
        └── unittest
vendor
└──huawei
        └──camera
                └──init_configs  # init configuration files (in JSON format, and deployed in /etc/init.cfg after image burning)

Constraints

Currently, the init module applies only to small-system devices reference memory ≥ 1 MB, for example, Hi3516D V300 and Hi3518E V300.

Usage

init divides the system startup into three phases:

pre-init: operations required before system services are started, for example, mounting a file system, creating a folder, and modifying permissions

init: operations required for starting system services.

post-init: operations required after system services are started.

In the init.cfg file, each of the preceding phases is represented by a job, which corresponds to a command set. The init_lite module initializes the system by executing the commands in each job in sequence. Jobs are executed in the following sequence: pre-init > init > post-init. All jobs are stored in the jobs array in the init.cfg file.

In addition to the jobs array, the init.cfg file also provides a services array, which is used to store the names, executable file paths, permissions, and other attribute information of the key system services that need to be started by the init process.

The file is stored in /vendor/hisilicon/hispark_aries/init_configs/ under /etc/. It is in JSON format, and its size cannot exceed 100 KB.

The format and content of the init.cfg file are as follows:

{
    "jobs" : [{
            "name" : "pre-init",
            "cmds" : [
                "mkdir /testdir",
                "chmod 0700 /testdir",
                "chown 99 99 /testdir",
                "mkdir /testdir2",
                "mount vfat /dev/mmcblk0p0 /testdir2 noexec nosuid"
            ]
        }, {
            "name" : "init",
            "cmds" : [
                "start service1",
                "start service2"
             ]
        }, {
             "name" : "post-init",
             "cmds" : []
        }
    ],
    "services" : [{
            "name" : "service1",
            "path" : "/bin/process1",
            "uid" : 1,
            "gid" : 1,
            "secon" : "u:r:untrusted_app:s0",
            "once" : 0,
            "importance" : 1,
            "caps" : [0, 1, 2, 5]
    }, {
            "name" : "service2",
            "path" : "/bin/process2",
            "uid" : 2,
            "gid" : 2,
            "secon" : "u:r:untrusted_app:s0",
            "once" : 1,
            "importance" : 0,
            "caps" : []
        }
    ]
}

Table 1 Job description

Job Name

Description

pre-init

Job that is executed first. Operations (for example, creating a folder) required before the process startup are executed in this job.

init

Job that is executed in between. Operations (for example, service startup) are executed in this job.

post-init

Job that is finally executed. Operations (for example, mounting the device after the driver initialization) required after the process startup are executed in this job.

A single job can hold a maximum of 30 commands only **start**, **mkdir**, **chmod**, **chown**, **mount**, and **loadcfg** are supported currently. The command name and parameters 128 bytes or less must be separated by only one space.

Table 2 Commands supported by a job

Command

Format and Example

Description

mkdir

mkdir target folder

Example: mkdir /storage/myDirectory

Creates a folder. mkdir and the target folder must be separated by only one space.

chmod

chmod permission target

Examples: chmod 0600 /storage/myFile.txt

chmod 0750 /storage/myDir

Modifies the permission, which must be in the 0xxx format. chmod, permission, and target must be separated by only one space.

chown

chown uid gid target

Example: chown 900 800 /storage/myDir

chown 100 100 /storage/myFile.txt

Modifies the owner group. chown, uid, gid, and target must be separated by only one space.

mount

mount fileSystemType src dst flags data

Example: mount vfat /dev/mmcblk0 /sdc rw,umask=000

mount jffs2 /dev/mtdblock3 /storage nosuid

Mounts devices. Every two parameters must be separated by only one space. Currently, supported flags include nodev, noexec, nosuid, rdonly, and optionally data.

start

start serviceName

Example: start foundation

start shell

Starts services. serviceName must be contained in the services array.

loadcfg

loadcfg filePath

Example: loadcfg /patch/fstab.cfg

Loads other .cfg files. The maximum size of the target file (only /patch/fstab.cfg supported currently) is 50 KB. Each line in the /patch/fstab.cfg file is a command. The command types and formats must comply with their respective requirements mentioned in this table. A maximum of 20 commands are allowed.

Table 3 Elements in the services array

Field

Description

name

Name of the current service. The value cannot be empty and can contain a maximum of 32 bytes.

path

Full path (including parameters) of the executable file for the current service. This is an array. Ensure that the first element is the path of the executable file, the maximum number of elements is 20, and each element is a string that contains a maximum of 64 bytes.

uid

User ID (UID) of the current service process.

gid

Group ID (GID) of the current service process.

secon

Security context of the current service process (no need to set currently).

once

Whether the current service process is a one-off process.

1: The current service process is a one-off process. If the process exits, the init process does not restart it.

0: The current service process is not a one-off process. If the process exits, the init process restarts it upon receiving the SIGCHLD signal.

Note: If a non-one-off process exits for five consecutive times within four minutes, the init process will no longer restart it at the fifth exit.

importance

Whether the current service process is a key system process.

0: The current service process is not a key system process. If it exits, the init process does not reset or restart the system.

1: The current service process is a key system process. If it exits, the init process resets and restarts the system.

caps

Capabilities required by the current service. They are evaluated based on the capabilities supported by the security subsystem and configured in accordance with the principle of least permission. Currently, a maximum of 100 values can be configured.

Repositories Involved

Startup subsystem

startup_syspara_lite

startup_appspawn_lite

startup_bootstrap_lite

[startup_init_lite]