Service Management

Overview

Function

Service configuration allows you to configure services on demand to create different value-added services. Currently, the following value-added services are supported: startup control, on-demand startup, command execution, scheduled startup, FD proxy, and sandbox.

Basic Concepts

• init service parameter options

  For details, see Description of service 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.

  The following is an example of service configuration:

  "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 setting for service processes
      "cpucore" : [0],                   // CPU binding for service processes
      "critical" : [1, 5, 10],           // Suppression for service processes
      "apl" : "normal",                  // Ability privilege level setting for service processes
      "d-caps" : ["OHOS_DMS"],           // Distributed capability setting for service processes
      "secon" : "u:r:distributedsche:s0" // SELinux tag setting for service processes. In this example, u:r:distributedsche:s0 is the SELinux tag.
  }
  

• SELinux tag

  To enable the SELinux policy for a service, add the SELinux tag to the service in the secon field. For example, to add the SELinux tag to watchdog_service, use the following code snippet:

  "services" : [{
            "name" : "watchdog_service",
            "secon" : "u:r:watchdog_service:s0"
  }]
  

  Note that you need to define the tag in SELinux. For details, see the appropriate SELinux guide.

• init service FD proxy (for standard system or higher)

  FD proxy is an extended mechanism for on-demand startup. It can ensure that the FD state handle is not lost before the service process exits. Specifically, a service process sends the FD to the init process before it exits, and then reclaims the FD from the init process when it is started again.

  This mechanism is implemented using the API provided by the init process. Before a service process exits, it can call the related API to send the FD to the init process over the socket that supports IPC communication. After the service process is restarted, the init process returns the corresponding FD handle to it in the same way. For details about the APIs, see FD Proxy APIs.

• 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
  

• Sandbox

  For details, see Sandbox Management.

Constraints

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

How to Develop

Use Cases

By parsing the *.cfg file, you can obtain service fields, and then set and start the service.

Parameters

Table 1 Description of service fields

Table 2 Description of socket fields

Available APIs

Table 3 FD proxy APIs

Table 4 Service control APIs

• DAC configuration for service control APIs

  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 };
  

How to Develop

The following describes how to add a system service named MySystemApp:

{
    "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.
        "socket" : [{
          "name" : "ueventd",
          "family" : "AF_NETLINK",
          "type" : "SOCK_DGRAM",
          "protocol" : "NETLINK_KOBJECT_UEVENT",
          "permissions" : "0660",
          "uid" : "system",
          "gid" : "system",
          "option" : [
            "SOCKET_OPTION_PASSCRED",
            "SOCKET_OPTION_RCVBUFFORCE",
            "SOCK_CLOEXEC",
            "SOCK_NONBLOCK"
          ]
        }],
        "uid" : 20,                   // UID of the MySystemApp service: 20
        "gid" : 20,                   // GID of the MySystemApp service: 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.
        "start-mode" : "condition",
        "critical": [1, 2, 10],       // Configure the critical field for MySystemApp system services. You need to pass three parameters, wherein, 1 means to enable system restarting, 2 means the number of times the critical service is restarted, and 10 means the time within which the critical service is restarted.
        "cpucore" : [0, 1],           // The device has two cores and both of them are bound to the CPU.
        "apl" : "system_core",
        "d-caps" : ["OHOS_DMS"],
        "jobs" : {
            "on-boot" : "boot",
            "on-start" : "services:MySystemApp_start",
            "on-stop" : "services:MySystemApp_stop",
            "on-restart" : "services:MySystemApp_restart"
        }
      }
    ]
}

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 verify that the process will be restarted.
3. Run the kill command to kill the MySystemApp process, and verify that the development board will not be restarted.

FAQs

Service Not Exist

Symptom

"Failed get servName" is recorded in the kernel log.

Cause Analysis

After a code review on the init process, it is found that the service does not exist.

Solution

1. Check whether the service is correctly configured in the .cfg file.
2. Check whether the .cfg file of the service is loaded normally.
3. Check whether the format of the .cfg file is correct.

Requesting FD Proxy for Other Services Failed

Symptom

"Service' xxx '(pid = xxx) is not valid or request with unexpected process(pid = xxx)" is recorded in the kernel log.

Cause Analysis

The kernel log is printed by the init process. After a code review on the init process, it is found that FD proxy is requested for other services.

Solution

Request FD proxy for the current service, but not other services.