# init Module The init module starts key service processes during system startup. If you would like to add a system service that automatically starts upon system startup, you can add the service to the **init.cfg** file. ## Configuration File The configuration file **init.cfg** of the init module contains service names, executable file paths, permissions, and other information of all key system services that need to be started by the init process. The file is stored in the code repository **vendor/huawei/camera/init\_configs/**, and can be found in **/etc/** after burning is complete. The file is in JSON format, and its size cannot exceed 100 KB. After the init process starts, it reads the **/etc/init.cfg** file, parses the content in JSON format, and loads system services in sequence based on the parsing result. ## How to Develop 1. Configure the **jobs** array. The init module completes the system startup in 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. Each of the preceding phases is represented by a job, which corresponds to a command set. The init module initializes the system by executing the commands in each job in sequence. pre-init job is executed first, then init job, and finally post-init job. ``` "jobs" : [{ "name" : "pre-init", "cmds" : [ "mkdir /testdir", "chmod 0700 /testdir", "chown 99 99 /testdir", "mkdir /testdir2", "mount vfat /dev/mmcblk0p0 /testdir2 noexec nosuid" // mount command (format: mount file system type source target flags data) ] }, { "name" : "init", "cmds" : [ "start service1", "start service2" ] }, { "name" : "post-init", "cmds" : [] } ], ``` **Table 1** Job execution

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/loadcfg** 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 0 xxx 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.

2. Configure the **services** array, which holds all system services \(a maximum of 100\) that need to be started by the init process. ``` "services" : [{ "name" : "service1", "path" : ["/bin/process1", "param1", "param2"], "uid" : 1, "gid" : 1, "once" : 0, "importance" : 1, "caps" : [0, 1, 2, 5] }, { "name" : "service2", "path" : "/bin/process2", "uid" : 2, "gid" : 2, "once" : 1, "importance" : 0, "caps" : [ ] } ] ``` **Table 3** Elements in the **services** array

Element	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.
once	Whether the current service process is a one-off process. 1: The current service 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.

## How to Use The following uses the MySystemApp service as an example to illustrate how to use the init process to start a system service. ``` { "jobs" : [{ "name" : "pre-init", "cmds" : [ "mkdir /storage/MyDir", // Create a folder before starting the MySystemApp service. This operation is executed in the pre-init job. "chmod 0600 /storage/MyDir", // Modify the permission because the MySystemApp service requires that only the current user and its owner group have the read and write permissions on the file. "chown 10 10 /storage/MyDir" ] }, { "name" : "init", "cmds" : [ "start MySystemApp" // Start the MySystemApp service in the init job. ] }, { "name" : "post-init", "cmds" : [] // Do not configure the post-init job because no other operations are required after the MySystemApp system service is started. } ], "services" : [{ "name" : "MySystemApp", // Name of the system service "path" : ["/bin/MySystemAppExe", "param1", "param2", "param3"], // The executable file path of the MySystemApp service is /bin/MySystemAppExe. To start the service, three parameters ("param1", "param2", and "param3") need to be passed. "uid" : 20, // The UID of the MySystemApp service is 20. "gid" : 20, // The GID of the MySystemApp service is 20. "once" : 0, // Not a one-off process of the MySystemApp service. If MySystemApp exits, the init process needs to restart it. "importance" : 0, // Not a key system process of the MySystemApp service. If MySystemApp exits, the init process does not need to restart the development board. "caps" : [] // Do not perform capability-related operations because capabilities are not required by the MySystemApp service. } ] } ``` After the configuration is complete, compile the package to burn the board. 1. Run the **task -a** command for liteos-a or **ps** for Linux to check whether the MySystemApp service process is started. 2. Run the **kill** command to kill the MySystemApp process, and then verify that the process will be restarted. 3. Run the **kill** command to kill the MySystemApp process, and then verify that the development board will not be restarted.