Service Management

Overview

Service management is implemented by using the init process to parse the service process configuration files (xxx.cfg files), which are used to configure services based on service scenarios. Currently, the supported value-added services include startup control, on-demand startup, command execution, scheduled startup, FD proxy, and sandbox management.

Description of Service Process Configuration Files

• Naming:

  Generally, the configuration file is named in the format of serviceName.cfg, where serviceName is the service process name, for example, appspawn.cfg.

• Format:

  The configuration file is based on the JSON format and complies with the basic rules of the JSON file.

• Content:

  The configuration file contains the following fields. Except mandatory fields, other fields can be configured based on service features.

  Table 1 Service configuration fields

Table 2 Description of socket fields

• init service startup control (for standard system or higher)

  The init process classifies services into three types based on service configurations and starts the services in different phases.

  • boot: services that need to be preferentially started in the system. This type of services are started in the init phase.
  • normal: common services in the system. This type of services are started in the post-init phase. This is the default service type.
  • condition: services that are started by running the startup command. You can add the start xxxx command to jobs to start the corresponding service.

• init service command execution (for standard system or higher)

  The init module provides the service command execution function, which allows services to execute different commands in different phases.

  • on-start: execution of commands after the service process is forked. The on-start job is executed in the subprocess of the service and affects only the subprocess.
  • on-stop: execution of commands in the init process when the service is stopped.
  • on-restart: execution of commands in the init process when the service is restarted.

  Configure the parameters as follows:

  "services" : [{
        "name" : "serviceName",
        "path" : ["/system/bin/serviceName"]
        "jobs" : {
            "on-boot" : "boot",
            "on-start" : "services:serviceName_start",
            "on-stop" : "services:serviceName_stop",
            "on-restart" : "services:serviceName_restart"
      }
  },
  

With the parallel startup and command execution capabilities, processes can be started concurrently.

• init service on-demand startup

  If on-demand startup is enabled, the init process starts a service only when it is required. The ondemand attribute is used to determine whether to enable on-demand startup for a service.

  The following is an example configuration of the ondemand attribute:

    "services" : [{
      "name" : "serviceName",
      "path" : ["/system/bin/serviceName"]
      "ondemand" : true
  }]
  

• SA process on-demand startup

  For details, see samgr Usage.

• Socket process on-demand startup

  1. The init process creates a socket for socket processes in the pre-fork phase and listens to read/write events on this socket.
  2. If a read/write event is received over the socket, the init process starts the native service corresponding to the socket process, cancels event listening on the socket, and transfers the socket to the corresponding native service for management.
  3. The native service automatically exits if no more packets need to be processed. When reclaiming subprocesses, the init process starts event listening over the socket again based on the service configuration.

• Hot-swap service process on-demand startup

  The hot-swap service process can be started to process hot swap events based on system parameter changes.

• Enhanced init process startup and recycling

  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)

  The following is the example configuration for enhanced init process startup and recycling:

  "services" : [{
      "name" : "serviceName",
      "path" : ["/system/bin/serviceName"]
      "importance" : 1,                  // Priority for service processes
      "cpucore" : [0],                   // CPU binding for service processes
      "critical" : [1, 5, 10],           // Suppression for service processes
      "apl" : "normal",                  // Ability privilege level for service processes
      "d-caps" : ["OHOS_DMS"],           // Distributed capabilities for service processes
      "secon" : "u:r:distributedsche:s0" // SELinux tag for service processes. In this example, the SELinux tag is u:r:distributedsche:s0.
  }
  

• Scheduled startup

  Scheduled startup means to start a service at the specified time. If the service has been started, it will not be started again. For details about the command, see Description of begetctl Commands.

  timer_start servicename timeout
  

Basic Process of Creating a Service Process

Configuring the Service Process Configuration File

After finishing the service process code, create the serviceName.cfg file (serviceName indicates the service process name) and configure the file content based on service features.

Install the configuration file in the corresponding directory. Configure the /base/startup/init/services/etc/BUILD.gn file of the init module as follows:

ohos_prebuilt_etc("watchdog.cfg") {
  source = "//base/startup/init/services/etc/watchdog.cfg"
  relative_install_dir = "init"
  part_name = "init"
  subsystem_name = "startup"
}

ohos_prebuilt_etc("console.cfg") {
  source = "//base/startup/init/services/etc/console.cfg"
  relative_install_dir = "init"
  part_name = "init"
  subsystem_name = "startup"
}

Add the build path of the configuration file to the bundle.json file of the corresponding module. For example:

    "build": {
        "group_type": {
            "base_group": [],
            "fwk_group": [],
            "service_group": [
                "//base/startup/init/ueventd:startup_ueventd",
                "//base/startup/init/services/etc:ueventd.cfg"
            ]
          },
    }

Configuring the DAC Permission for a Service Process

Configure the DAC permission for the desired service process based on the GID and UID in the service process configuration file.

If the corresponding GID and UID do not exist, add them to the /init/services/etc/passwd and /init/services/etc/group files of the init module.

• Description of the passwd file:

• Each entry corresponds to a user. User information is separated by colons (:) and divided into seven fields, as shown below:

  root:x:0:0:::/bin/false
  bin:x:2:2:::/bin/false
  system:x:1000:1000:::/bin/false
  

Fields in the passwd file

• Description of the group file

• Each entry corresponds to a user group. User group information is separated by colons (:) and divided into four fields, as shown below:

  root:x:0:
  bin:x:2:
  system:x:1000:
  servicectrl:x:1050:root,shell,system,samgr,hdf_devmgr,foundation,update
  

Fields in the group file

• If the GID and UID are set to root or system, add a trustlist to the security_config/high_privilege_process_list.json file in the corresponding product directory. For example:

  {
      "high_privilege_process_list": [
          {
              "name": "appspawn",
              "uid": "root",
              "gid": "root"
          },
          {
              "name": "console",
              "uid": "root"
          },
          {
              "name": "testService",
              "uid": "root",
              "gid": "root"
          },
          {
              "name": "media_service",
              "gid": ["root", "system"]
          },
          {
              "name": "misc",
              "uid": "root",
              "gid": "root"
          } ... ...
      ]
  }

Configuring the SELinux Permission for a Service Process

• Configuring the SELinux permission

  1. Check whether the service process can be started in permissive mode. If yes, you do not need to configure the selinux tag.

  2. To configure SELinux rules, you need to set the SELinux tag in the secon field in the configuration file of the service process.

  3. Define the service process tag in the SELinux module. The procedure is as follows:

  Define the tag for program execution in the base/security/selinux_adapter/sepolicy/base/system/file_contexts file. For example:

    /system/bin/watchdog_service        u:object_r:watchdog_service_exec:s0
    /system/bin/hdcd        u:object_r:hdcd_exec:s0
  

  Define the applicable scope of the tag in the base/security/selinux_adapter/sepolicy/base/public/type.te file. For example:

    type watchdog_service, sadomain, domain;
    type watchdog_service_exec, exec_attr, file_attr, system_file_attr;
  

Error Codes

Description of error codes

Service Process Configuration Example

Example Code

Example Configuration

Available APIs

Table 3 Service control APIs

• The service management APIs are privileged APIs. Therefore, you need to configure the DAC and SELinux permissions as follows:

• Go to /base/startup/init/services/etc/group and add the correct user ID to servicectrl. For example:

```
servicectrl:x:1050:root,shell,system,samgr,hdf_devmgr
```

• SELinux configuration for service control APIs

  Add the required SELinux permissions to the init.te file. For example, grant the system parameter write permission for services such as init, samgr, and hdf_devmgr.

  allow { init samgr hdf_devmgr } servicectrl_param:parameter_service { set };
  

Constraints

The service management module is available only for the mini system and standard system.

FAQs

For details, see init Module FAQs.