Using systemd to Start a Container
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.
- 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.
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: 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