Using systemd to Start a Container

• Using systemd to Start a Container

Function Description

The init process started in system containers differs from that in common containers. Common containers cannot start system services through systemd. However, system containers have this capability. You can enable the systemd service by specifying the --system-container parameter when starting a system container.

Parameter Description

Constraints

• The systemd service needs to call some special system APIs, including mount, umount2, unshare, reboot, and name_to_handle_at. Therefore, permissions to call the preceding APIs are enabled for system containers when the privileged container tag is disabled.
• All system containers are started by the init process. The init process does not respond to the SIGTERM signal which indicates normal exit. By default, the stop command forcibly kills the container 10 seconds later. If you need a quicker stop, you can manually specify the timeout duration of the stop command.
• --system-container must be used together with --external-rootfs.
• Various services can run in a system container. The systemctl command is used to manage the service starting and stopping. Services may depend on each other. As a result, when an exception occurs, some service processes are in the D or Z state so that the container cannot exit properly.
• Some service processes in a system container may affect other operation results. For example, if the NetworkManager service is running in the container, adding NICs to the container may be affected (the NICs are successfully added but then stopped by the NetworkManger), resulting in unexpected results.
• Currently, system containers and hosts cannot be isolated by using udev events. Therefore, the fstab file cannot be configured.
• The systemd service may conflict with the cgconfig service provided by libcgroup. You are advised to delete the libcgroup-related packages from a container or set Delegate of the cgconfig service to no.

Example

• Specify the --system-container and --external-rootfs parameters to start a system container.

  [root@localhost ~]# isula run -tid -n systest01 --system-container --external-rootfs /root/myrootfs none init
  

• After the preceding commands are executed, the container is running properly. You can run the exec command to access the container and view the process information. The command output indicates that the systemd service has been started.

  [root@localhost ~]# isula exec -it systest01 bash
  [root@localhost /]# ps -ef
  UID        PID  PPID  C STIME TTY          TIME CMD
  root         1     0  2 06:49 ?        00:00:00 init
  root        14     1  2 06:49 ?        00:00:00 /usr/lib/systemd/systemd-journal
  root        16     1  0 06:49 ?        00:00:00 /usr/lib/systemd/systemd-network
  dbus        23     1  0 06:49 ?        00:00:00 /usr/bin/dbus-daemon --system --
  root        25     0  0 06:49 ?        00:00:00 bash
  root        59    25  0 06:49 ?        00:00:00 ps –ef
  

• Run the systemctl command in the container to check the service status. The command output indicates that the service is managed by systemd.

  [root@localhost /]# systemctl status dbus
  ● dbus.service - D-Bus System Message Bus
     Loaded: loaded (/usr/lib/systemd/system/dbus.service; static; vendor preset:
  disabled)
     Active: active (running) since Mon 2019-07-22 06:49:38 UTC; 2min 5
  8s ago
       Docs: man:dbus-daemon(1)
   Main PID: 23 (dbus-daemon)
     CGroup: /system.slice/dbus.service
             └─23 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidf
  ile --systemd-activation --syslog-only
  
  Jul 22 06:49:38 localhost systemd[1]: Started D-Bus System Message Bus.
  

• Run the systemctl command in the container to stop or start the service. The command output indicates that the service is managed by systemd.

  [root@localhost /]# systemctl stop dbus
  Warning: Stopping dbus.service, but it can still be activated by:
    dbus.socket
  [root@localhost /]# systemctl start dbus