init Module
The init module starts key service processes during system startup. If you want to enable some system services to automatically start upon system startup, include the service information in the configuration file init.cfg.
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
-
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
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
-
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
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.
- Run the task -a command for liteos-a or ps for Linux to check whether the MySystemApp service process is started.
- Run the kill command to kill the MySystemApp process, and then verify that the process will be restarted.
- Run the kill command to kill the MySystemApp process, and then verify that the development board will not be restarted.