@@ -18,9 +18,9 @@ Only the small system and standard system are supported.
## How to Develop
### Use Cases
Upon startup, the init process first initializes the system and then parses the configuration file. The system classifies the configuration files into three types:
1.init.cfg: default configuration file, which is defined by the init process and parsed first.
2./system/etc/init/*.cfg: configuration file defined by each subsystem.
3./vendor/etc/init/*.cfg: configuration file defined by vendors.
1.<strong>init.cfg</strong>: default configuration file, which is defined by the init process and parsed first.
2.<strong>/system/etc/init/*.cfg</strong>: configuration file defined by each subsystem.
3.<strong>/vendor/etc/init/*.cfg</strong>: configuration file defined by vendors.
If you need to add a configuration file, define its content as you want and copy it to the corresponding directory.
...
...
@@ -81,14 +81,14 @@ The following is a template for defining a **.cfg** file.
]
}
```
1..cfg file: configuration file written in the JSON format. If the services or commands in it do not take effect, check whether the content format is correct.
1.<strong>.cfg file</strong>: configuration file written in the JSON format. If the services or commands in it do not take effect, check whether the content format is correct.
2.import: command used to import **.cfg** files. The files are parsed immediately after their path is parsed.
2.<strong>import</strong>: command used to import **.cfg** files. The files are parsed immediately after their path is parsed.
3.example1.cfg: **.cfg** file to be imported.
3.<strong>example1.cfg</strong>: **.cfg** file to be imported.
4.serviceName: service name, which is user-defined.
4.<strong>serviceName</strong>: service name, which is user-defined.
5./system/bin/serviceName: full path and parameters of the executable file of the current service, in array format.
5.<strong>/system/bin/serviceName</strong>: full path and parameters of the executable file of the current service, in array format.
6.jobName1: job name, which is user-defined.
6.<strong>jobName1</strong>: job name, which is user-defined.
For details, see [begetctl Commands](#table14737791480).
- begetctl
For details about begetctl, see [begetctl Commands](#table14737791480).
- bootchart plug-in
The bootchart plug-in is an open source tool used to evaluate system performance during Linux startup. It automatically collects information such as the CPU usage, disk throughput, and process status, and displays the evaluation result in graphics to facilitate system startup optimization.
### Constraints
...
...
@@ -149,8 +153,8 @@ bootchart is available only for the standard system, and begetctl is available f
proc_diskstats.log<br>
proc_ps.log<br>
proc_stat.log<br>
7. Run the **tar -zcvf bootchart.tgz *** command to compress the **bootchart.tgz** file (available only for Linux) and copy the compressed file to the **linux:bootchart-master** directory.
8. Run the following command in the **bootchart-master** directory:
7. Run the <strong>tar -zcvf bootchart.tgz *</strong> command to compress the <strong>bootchart.tgz</strong> file (available only for Linux) and copy the compressed file to the <strong>linux:bootchart-master</strong> directory.
8. Run the following command in the <strong>bootchart-master</strong> directory:
@@ -70,11 +70,11 @@ Service configuration allows you to configure services on demand to create diffe
The CPU core binding, priority, MAC address, and AccessToken information of the service process can be configured in the configuration file during process startup.
- Support of CPU core binding for service processes (through modification of the **\*.cfg** file)
- Support of priority setting for service processes (through modification of the **\*.cfg** file)
- Support of MAC address setting (that is, SELinux tag setting) for service processes (through modification of the **\*.cfg** file)
- Support of AccessToken setting for service processes and distributed capability setting for system service processes (through modification of the **\*.cfg** file)
- Support of the suppression mechanism for service processes (through modification of the **\*.cfg** file)
- Support of CPU core binding for service processes (through modification of the <strong>*.cfg</strong> file)
- Support of priority setting for service processes (through modification of the <strong>*.cfg</strong> file)
- Support of MAC address setting (that is, SELinux tag setting) for service processes (through modification of the <strong>*.cfg</strong> file)
- Support of AccessToken setting for service processes and distributed capability setting for system service processes (through modification of the <strong>*.cfg</strong> file)
- Support of the suppression mechanism for service processes (through modification of the <strong>*.cfg</strong> file)
The following is the example configuration for enhanced init process startup and recycling:
```
...
...
@@ -111,7 +111,7 @@ The service management module is available only for the mini system and standard
## How to Develop
### Use Cases
By parsing the ***.cfg** file, you can obtain **service** fields, and then set and start the service.
By parsing the <strong>*.cfg</strong> file, you can obtain **service** fields, and then set and start the service.
### Parameters
**Table 1** Description of service fields
...
...
@@ -240,8 +240,8 @@ By parsing the ***.cfg** file, you can obtain **service** fields, and then set a
Suppression mechanism for services. If the number of times a service is restarted exceeds the value N within the specified period T, the system will be restarted.
Standard system:<br>Type: int array, for example, **"critical": [M, N, T]**.<br>- **M**: enable flag (**0**: disable; **1**: enable).<br>- **N**: number of times the service is started.<br>- **T**: period of time, in seconds.<br> Both **M** and **N** are greater than **0**.<br>
Small and standard systems:<br>Type: int, for example, **"critical": M**.<br>M: enable flag (**0**: disable; **1**: enable).<br> By default, **N** is **4** and **T** is **20**.
Standard system:<br>Type: int array, for example, <strong>"critical": [M, N, T]</strong>.<br>- **M**: enable flag (**0**: disable; **1**: enable).<br>- **N**: number of times the service is started.<br>- **T**: period of time, in seconds.<br> Both **M** and **N** are greater than **0**.<br>
Small and standard systems:<br>Type: int, for example, <strong>"critical": M</strong>.<br>**M**: enable flag (**0**: disable; **1**: enable).<br> By default, **N** is **4** and **T** is **20**.
Type: int array, for example, **"cpucore": [N1, N2, ...]**. **N1** and **N2** indicate the indices of the CPU cores to be bound. For a single-core device, **cpucore** is **0**.
Type: int array, for example, <strong>"cpucore": [N1, N2, ...]</strong>. **N1** and **N2** indicate the indices of the CPU cores to be bound. For a single-core device, **cpucore** is **0**.
Type: string, for example, **"start-mode": "condition"**. The value can be **boot**, **normal**, or **condition**. For details, see init Service Startup Control.</a>
Type: string, for example, <strong>"start-mode": "condition"</strong>. The value can be **boot**, **normal**, or **condition**. For details, see init Service Startup Control.</a>
Type: bool, for example, **"ondemand": true**. This feature is available only for the small system running the Linux kernel. For details, see init Service On-Demand Startup.</a>
Type: bool, for example, <strong>"ondemand": true</strong>. This feature is available only for the small system running the Linux kernel. For details, see init Service On-Demand Startup.</a>
@@ -359,10 +359,10 @@ By parsing the ***.cfg** file, you can obtain **service** fields, and then set a
| permissions | Permissions of the socket node file. This field is valid only for sockets that have entity node files, such as the AF_UNIX address family.|
| uid | User ID of the socket node file. This field is valid only for sockets that have entity node files, such as the AF_UNIX address family.|
| gid | Group ID of the socket node file. This field is valid only for sockets that have entity node files, such as the AF_UNIX address family.|
| option | Socket option. This field is passed when **setsockopt** is called. Currently, the available options include **SOCKET_OPTION_PASSCRED**, **SOCKET_OPTION_RCVBUFFORCE**, **SOCK_CLOEXEC**, and **SOCK_NONBLOCK**.|
| option | Socket option. This field is passed when **setsockopt** is called. Currently, the available options include <strong>SOCKET_OPTION_PASSCRED</strong>, <strong>SOCKET_OPTION_RCVBUFFORCE</strong>, <strong>SOCK_CLOEXEC</strong>, and <strong>SOCK_NONBLOCK</strong>.|
| int *ServiceGetFd(const char *serviceName, size_t *outfdCount) | Obtains the proxy FD from the init process.| Return value: Returns the pointer to the fd array if the operation is successful; returns **NULL** otherwise. (Note: Manual release is required.)<br>Arguments:<br> **serviceName**: service name.<br>**outfdCount**: length of the returned fd array.|
@@ -26,10 +26,10 @@ Figure 1 System parameter operation primitives
**Table 2** System parameter names
| Type| Example| Description|
| -------- | -------- | -------- |
| Parameter name | const.product.**name** | Complete system parameter name. It does not end with a period (.). |
| Parameter directory | const.product **.** | Name of the directory storing system parameters with the same prefix. It ends with a period (.).|
| Type| Name| Example| Description|
| -------- | -------- | -------- | -------- |
| Name| Parameter Name | const.product.**name** | Complete system parameter name. It does not end with a period (.). |
| Directory| Parameter Directory | const.product **.** | Name of the directory storing system parameters with the same prefix. It ends with a period (.).|
- Type
...
...
@@ -90,11 +90,11 @@ Each subsystem defines the system parameters of its own modules, including the s
const.product.="root:root:660"
```
As shown above, we can use **parameter directory** to define the same access permission for system parameters with the same prefix. The DAC information is divided into three segments, user, group, and UGO rule information, which are separated using a semicolon (:).
As shown above, we can use **parameter directory** to define the same access permission for system parameters with the same prefix. The DAC information is divided into three segments, user, group, and UGO rule, which are separated using a semicolon (:).
The following figure shows the structure of the UGO rule information.
The following figure shows the structure of the UGO rule.
**Figure 2** UGO rule information
**Figure 2** UGO rule structure
...
...
@@ -132,7 +132,7 @@ You can set specific system parameters as needed to meet your service demand.
| -------- | -------- |
| param get [**key**] | Obtains the system parameter value of the specified key. If no key name is specified, all system parameter values will be returned.|
| param set **key value** | Sets the specified value for the specified key.|
| param wait **key** **value** | Waits for the system parameter value of the specified key to match the specified value. Fuzzy match is supported. For example, ***** indicates any value, and **val*** indicates matching of only the first three val characters.|
| param wait **key** **value** | Waits for the system parameter value of the specified key to match the specified value. Fuzzy match is supported. For example, <strong>*</strong> indicates any value, and <strong>val*</strong> indicates matching of only the first three val characters.|
| param watch | Observes value change of a system parameter asynchronously.|
- syspara APIs
...
...
@@ -177,9 +177,9 @@ You can set specific system parameters as needed to meet your service demand.
1. System parameter definition
You can define default system parameters and implement permission control on them by configuring the subsystem or product **.para** and **.para.dac** files.
You can define default system parameters and implement permission control on them by configuring the subsystem or product <strong>.para</strong> and <strong>.para.dac</strong> files.
On a standard system, use the **ohos_prebuilt_para** template to install the configuration file to the **/etc/param/** directory. The following is an example of the GN script:
On a standard system, use the <strong>ohos_prebuilt_para</strong> template to install the configuration file to the <strong>/etc/param/</strong> directory. The following is an example of the GN script:
@@ -197,7 +197,7 @@ You can set specific system parameters as needed to meet your service demand.
}
```
On a small system, run the **copy** command to copy the corresponding system parameter definition file to the **system/etc/param** directory.
On a small system, run the <strong>copy</strong> command to copy the corresponding system parameter definition file to the <strong>system/etc/param</strong> directory.
