Container Management
- Container Management
- Creating a Container
- Starting a Container
- Running a Container
- Stopping a Container
- Forcibly Stopping a Container
- Removing a Container
- Attaching to a Container
- Renaming a Container
- Executing a Command in a Running Container
- Querying Information About a Single Container
- Querying Information About All Containers
- Restarting a Container
- Waiting for a Container to Exit
- Viewing Process Information in a Container
- Displaying Resource Usage Statistics of a Container
- Obtaining Container Logs
- Copying Data Between a Container and a Host
- Pausing a Container
- Resuming a Container
- Obtaining Event Messages from the Server in Real Time
Creating a Container
Description
To create a container, run the isula create command. The container engine will use the specified container image to create a read/write layer, or use the specified local rootfs as the running environment of the container. After the creation is complete, the container ID is output as standard output. You can run the isula start command to start the container. The new container is in the inited state.
Usage
isula create [OPTIONS] IMAGE [COMMAND] [ARG...]
Parameters
The following table lists the parameters supported by the create command.
Table 1 Parameter description
Constraints
When the --user or --group-add parameter is used to verify the user or group during container startup, if the container uses an OCI image, the verification is performed in the etc/passwd and etc/group files of the actual rootfs of the image. If a folder or block device is used as the rootfs of the container, the etc/passwd and etc/group files in the host are verified. The rootfs ignores mounting parameters such as -v and --mount. That is, when these parameters are used to attempt to overwrite the etc/passwd and etc/group files, the parameters do not take effect during the search and take effect only when the container is started. The generated configuration is saved in the iSulad root directory/engine/container ID/start_generate_config.json file. The file format is as follows:
{ "uid": 0, "gid": 8, "additionalGids": [ 1234, 8 ] }
Example
Create a container.
$ isula create busybox
fd7376591a9c3d8ee9a14f5d2c2e5255b02cc44cddaabca82170efd4497510e1
$ isula ps -a
STATUS PID IMAGE COMMAND EXIT_CODE RESTART_COUNT STARTAT FINISHAT RUNTIME ID NAMES inited - busybox "sh" 0 0 - - lcr fd7376591a9c fd7376591a9c4521...
Starting a Container
Description
To start one or more containers, run the isula start command.
Usage
isula start [OPTIONS] CONTAINER [CONTAINER...]
Parameters
The following table lists the parameters supported by the start command.
Table 1 Parameter description
Container runtime. The parameter value can be lcr, which is case insensitive. Therefore, LCR and lcr are equivalent. |
Example
Start a new container.
$ isula start fd7376591a9c3d8ee9a14f5d2c2e5255b02cc44cddaabca82170efd4497510e1
Running a Container
Description
To create and start a container, run the isula run command. You can use a specified container image to create a container read/write layer and prepare for running the specified command. After the container is created, run the specified command to start the container. The run command is equivalent to creating and starting a container.
Usage
isula run [OPTIONS] ROOTFS|IMAGE [COMMAND] [ARG...]
Parameters
The following table lists the parameters supported by the run command.
Table 1 Parameter description
Constraints
When the parent process of a container exits, the corresponding container automatically exits.
When a common container is created, the parent process cannot be initiated because the permission of common containers is insufficient. As a result, the container does not respond when you run the attach command though it is created successfully.
If --net is not specified when the container is running, the default host name is localhost.
If the --files-limit parameter is to transfer a small value, for example, 1, when the container is started, iSulad creates a cgroup, sets the files.limit value, and writes the PID of the container process to the cgroup.procs file of the cgroup. At this time, the container process has opened more than one handle. As a result, a write error is reported, and the container fails to be started.
If both** --mount** and --volume exist and their destination paths conflict, --mount will be run after --volume (that is, the mount point in --volume will be overwritten).
Note: The value of the type parameter of lightweight containers can be bind or squashfs. When type is set to squashfs, src is the image path. The value of the type parameter of the native Docker can be bind, volume, and tmpfs.
The restart policy does not support unless-stopped.
The values returned for Docker and lightweight containers are 127 and 125 respectively in the following three scenarios:
The host device specified by --device does not exist.
The hook JSON file specified by --hook-spec does not exist.
The entry point specified by --entrypoint does not exist.
When the --volume parameter is used, /dev/ptmx will be deleted and recreated during container startup. Therefore, do not mount the /dev directory to that of the container. Use --device to mount the devices in /dev of the container.
Do not use the echo option to input data to the standard input of the run command. Otherwise, the client will be suspended. The echo value should be directly transferred to the container as a command line parameter.
[root@localhost ~]# echo ls | isula run -i busybox /bin/sh ^C [root@localhost ~]#
The client is suspended when the preceding command is executed because the preceding command is equivalent to input ls to stdin. Then EOF is read and the client does not send data and waits for the server to exit. However, the server cannot determine whether the client needs to continue sending data. As a result, the server is suspended in reading data, and both parties are suspended.
The correct execution method is as follows:
[root@localhost ~]# isula run -i busybox ls bin dev etc home proc root sys tmp usr var [root@localhost ~]#
If the root directory (/) of the host is used as the file system of the container, the following situations may occur during the mounting:
Table 2 Mounting scenarios
NOTICE:
Scenario 1: Mount /home/test1 and then /home/test2. In this case, the content in /home/test1 overwrites the content in /mnt. As a result, the abc directory does not exist in /mnt, and mounting** /home/test2** to /mnt/abc fails.
Scenario 2: Mount /home/test2 and then /home/test1. In this case, the content of /mnt is replaced with the content of /home/test1 during the second mounting. In this way, the content mounted during the first mounting from /home/test2 to /mnt/abc is overwritten.
The first scenario is not supported. For the second scenario, users need to understand the risk of data access failures.NOTICE:
- In high concurrency scenarios (200 containers are concurrently started), the memory management mechanism of Glibc may cause memory holes and large virtual memory (for example, 10 GB). This problem is caused by the restriction of the Glibc memory management mechanism in the high concurrency scenario, but not by memory leakage. Therefore, the memory consumption does not increase infinitely. You can set the MALLOC_ARENA_MAX environment variable to reduce the virtual memory and increase the probability of reducing the physical memory. However, this environment variable will cause the iSulad concurrency performance to deteriorate. Set this environment variable based on the site requirements.
To balance performance and memory usage, set MALLOC_ARENA_MAX to 4. (The iSulad performance deterioration on the ARM64 server is controlled by less than 10%.) Configuration method: 1. To manually start iSulad, run the export MALLOC_ARENA_MAX=4 command and then start the iSulad. 2. If systemd manages iSulad, you can modify the /etc/sysconfig/iSulad file by adding MALLOC_ARENA_MAX=4.
Example
Run a new container.
$ isula run -itd busybox
9c2c13b6c35f132f49fb7ffad24f9e673a07b7fe9918f97c0591f0d7014c713b
Stopping a Container
Description
To stop a container, run the isula stop command. The SIGTERM signal is sent to the first process in the container. If the container is not stopped within the specified time (10s by default), the SIGKILL signal is sent.
Usage
isula stop [OPTIONS] CONTAINER [CONTAINER...]
Parameters
The following table lists the parameters supported by the stop command.
Table 1 Parameter description
Time for graceful stop. If the time exceeds the value of this parameter, the container is forcibly stopped. |
Constraints
If the t parameter is specified and the value of t is less than 0, ensure that the application in the container can process the stop signal.
Principle of the Stop command: Send the SIGTERM signal to the container, and then wait for a period of time (t entered by the user). If the container is still running after the period of time, the SIGKILL signal is sent to forcibly kill the container.
The meaning of the input parameter t is as follows:
t < 0: Wait for graceful stop. This setting is preferred when users are assured that their applications have a proper stop signal processing mechanism.
t = 0: Do not wait and send kill -9 to the container immediately.
t > 0: Wait for a specified period and send kill -9 to the container if the container does not stop within the specified period.
Therefore, if t is set to a value less than 0 (for example, t = -1), ensure that the container application correctly processes the SIGTERM signal. If the container ignores this signal, the container will be suspended when the isula stop command is run.
Example
Stop a container.
$ isula stop fd7376591a9c3d8ee9a14f5d2c2e5255b02cc44cddaabca82170efd4497510e1
fd7376591a9c3d8ee9a14f5d2c2e5255b02cc44cddaabca82170efd4497510e1
Forcibly Stopping a Container
Description
To forcibly stop one or more running containers, run the isula kill command.
Usage
isula kill [OPTIONS] CONTAINER [CONTAINER...]
Parameters
The following table lists the parameters supported by the kill command.
Table 1 Parameter description
Example
Kill a container.
$ isula kill fd7376591a9c3d8ee9a14f5d2c2e5255b02cc44cddaabca82170efd4497510e1
fd7376591a9c3d8ee9a14f5d2c2e5255b02cc44cddaabca82170efd4497510e1
Removing a Container
Description
To remove a container, run the isula rm command.
Usage
isula rm [OPTIONS] CONTAINER [CONTAINER...]
Parameters
The following table lists the parameters supported by the rm command.
Table 1 Parameter description
Removes a volume mounted to a container. (Note: Currently, iSulad does not use this function.) |
Constraints
- In normal I/O scenarios, it takes T1 to delete a running container in an empty environment (with only one container). In an environment with 200 containers (without a large number of I/O operations and with normal host I/O), it takes T2 to delete a running container. The specification of T2 is as follows: T2 = max {T1 x 3, 5}s.
Example
Delete a stopped container.
$ isula rm fd7376591a9c3d8ee9a14f5d2c2e5255b02cc44cddaabca82170efd4497510e1
fd7376591a9c3d8ee9a14f5d2c2e5255b02cc44cddaabca82170efd4497510e1
Attaching to a Container
Description
To attach standard input, standard output, and standard error of the current terminal to a running container, run the isula attach command. Only containers whose runtime is of the LCR type are supported.
Usage
isula attach [OPTIONS] CONTAINER
Parameters
The following table lists the parameters supported by the attach command.
Table 1 Parameter description
Constraints
- For the native Docker, running the attach command will directly enter the container. For the iSulad container, you have to run the attach command and press Enter to enter the container.
Example
Attach to a running container.
$ isula attach fd7376591a9c3d8ee9a14f5d2c2e5255b02cc44cddaabca82170efd4497510e1
/ #
/ #
Renaming a Container
Description
To rename a container, run the isula rename command.
Usage
isula rename [OPTIONS] OLD_NAME NEW_NAME
Parameters
The following table lists the parameters supported by the rename command.
Table 1 Parameter description
Example
Rename a container.
$ isula rename my_container my_new_container
Executing a Command in a Running Container
Description
To execute a command in a running container, run the isula exec command. This command is executed in the default directory of the container. If a user-defined directory is specified for the basic image, the user-defined directory is used.
Usage
isula exec [OPTIONS] CONTAINER COMMAND [ARG...]
Parameters
The following table lists the parameters supported by the exec command.
Table 1 Parameter description
Constraints
If no parameter is specified in the isula exec command, the -it parameter is used by default, indicating that a pseudo terminal is allocated and the container is accessed in interactive mode.
When you run the isula exec command to execute a script and run a background process in the script, you need to use the nohup flag to ignore the SIGHUP signal.
When you run the isula exec command to execute a script and run a background process in the script, you need to use the nohup flag. Otherwise, the kernel sends the SIGHUP signal to the process executed in the background when the process (first process of the session) exits. As a result, the background process exits and zombie processes occur.
After running the isula exec command to access the container process, do not run background programs. Otherwise, the system will be suspended.
To run the isula exec command to execute a background process, perform the following steps:
- Run the isula exec container_name bash command to access the container.
- After entering the container, run the script & command.
- Run the exit command. The terminal stops responding.
After the isula exec command is executed to enter the container, the background program stops responding because the isula exec command is executed to enter the container and run the background while1 program. When the bash command is run to exit the process, the while1 program does not exit and becomes an orphan process, which is taken over by process 1. The while1 process is executed by the initial bash process fork &exec of the container. The while1 process copies the file handle of the bash process. As a result, the handle is not completely closed when the bash process exits. The console process cannot receive the handle closing event, epoll_wait stops responding, and the process does not exit.
Do not run the isula exec command in the background. Otherwise, the system may be suspended.
Run the isula exec command in the background as follows:
Run the isula exec script & command in the background, for example, isula exec container_name script &,isula exec. The command is executed in the background. The script continuously displays a file by running the cat command. Normally, there is output on the current terminal. If you press Enter on the current terminal, the client exits the stdout read operation due to the I/O read failure. As a result, the terminal does not output data. The server continues to write data to the buffer of the FIFO because the process is still displaying files by running the cat command. When the buffer is full, the process in the container is suspended in the write operation.
When a lightweight container uses the exec command to execute commands with pipe operations, you are advised to run the /bin/bash -c command.
Typical application scenarios:
Run the isula exec container_name -it ls /test | grep "xx" | wc -l command to count the number of xx files in the test directory. The output is processed by grep and wc through the pipe because ls /test is executed with exec. The output of ls /test executed by exec contains line breaks. When the output is processed, the result is incorrect.
Cause: Run the ls /test command using exec. The command output contains a line feed character. Run the** | grep "xx" | wc -l** command for the output. The processing result is 2 (two lines).
[root@localhost ~]# isula exec -it container ls /test xx xx10 xx12 xx14 xx3 xx5 xx7 xx9 xx1 xx11 xx13 xx2 xx4 xx6 xx8 [root@localhost ~]#
Suggestion: When running the run/exec command to perform pipe operations, run the /bin/bash -c command to perform pipe operations in the container.
[root@localhost ~]# isula exec -it container /bin/sh -c "ls /test | grep "xx" | wc -l" 15 [root@localhost ~]#
Do not use the echo option to input data to the standard input of the exec command. Otherwise, the client will be suspended. The echo value should be directly transferred to the container as a command line parameter.
[root@localhost ~]# echo ls | isula exec 38 /bin/sh ^C [root@localhost ~]#
The client is suspended when the preceding command is executed because the preceding command is equivalent to input ls to stdin. Then EOF is read and the client does not send data and waits for the server to exit. However, the server cannot determine whether the client needs to continue sending data. As a result, the server is suspended in reading data, and both parties are suspended.
The correct execution method is as follows:
[root@localhost ~]# isula exec 38 ls bin dev etc home proc root sys tmp usr var
Example
Run the echo command in a running container.
$ isula exec c75284634bee echo "hello,world"
hello,world
Querying Information About a Single Container
Description
To query information about a single container, run the isula inspect command.
Usage
isula inspect [OPTIONS] CONTAINER|IMAGE [CONTAINER|IMAGE...]
Parameters
The following table lists the parameters supported by the inspect command.
Table 1 Parameter description
Constraints
- Lightweight containers do not support the output in { {.State} } format but support the output in the { {json .State} } format. The -f parameter is not supported when the object is an image.
Example
Query information about a container.
$ isula inspect c75284634bee
[
{
"Id": "c75284634beeede3ab86c828790b439d16b6ed8a537550456b1f94eb852c1c0a",
"Created": "2019-08-01T22:48:13.993304927-04:00",
"Path": "sh",
"Args": [],
"State": {
"Status": "running",
"Running": true,
"Paused": false,
"Restarting": false,
"Pid": 21164,
"ExitCode": 0,
"Error": "",
"StartedAt": "2019-08-02T06:09:25.535049168-04:00",
"FinishedAt": "2019-08-02T04:28:09.479766839-04:00",
"Health": {
"Status": "",
"FailingStreak": 0,
"Log": []
}
},
"Image": "busybox",
"ResolvConfPath": "",
"HostnamePath": "",
"HostsPath": "",
"LogPath": "none",
"Name": "c75284634beeede3ab86c828790b439d16b6ed8a537550456b1f94eb852c1c0a",
"RestartCount": 0,
"HostConfig": {
"Binds": [],
"NetworkMode": "",
"GroupAdd": [],
"IpcMode": "",
"PidMode": "",
"Privileged": false,
"SystemContainer": false,
"NsChangeFiles": [],
"UserRemap": "",
"ShmSize": 67108864,
"AutoRemove": false,
"AutoRemoveBak": false,
"ReadonlyRootfs": false,
"UTSMode": "",
"UsernsMode": "",
"Sysctls": {},
"Runtime": "lcr",
"RestartPolicy": {
"Name": "no",
"MaximumRetryCount": 0
},
"CapAdd": [],
"CapDrop": [],
"Dns": [],
"DnsOptions": [],
"DnsSearch": [],
"ExtraHosts": [],
"HookSpec": "",
"CPUShares": 0,
"Memory": 0,
"OomScoreAdj": 0,
"BlkioWeight": 0,
"BlkioWeightDevice": [],
"CPUPeriod": 0,
"CPUQuota": 0,
"CPURealtimePeriod": 0,
"CPURealtimeRuntime": 0,
"CpusetCpus": "",
"CpusetMems": "",
"SecurityOpt": [],
"StorageOpt": {},
"KernelMemory": 0,
"MemoryReservation": 0,
"MemorySwap": 0,
"OomKillDisable": false,
"PidsLimit": 0,
"FilesLimit": 0,
"Ulimits": [],
"Hugetlbs": [],
"HostChannel": {
"PathOnHost": "",
"PathInContainer": "",
"Permissions": "",
"Size": 0
},
"EnvTargetFile": "",
"ExternalRootfs": ""
},
"Mounts": [],
"Config": {
"Hostname": "localhost",
"User": "",
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"TERM=xterm",
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Tty": true,
"Cmd": [
"sh"
],
"Entrypoint": [],
"Labels": {},
"Annotations": {
"log.console.file": "none",
"log.console.filerotate": "7",
"log.console.filesize": "1MB",
"rootfs.mount": "/var/lib/isulad/mnt/rootfs",
"native.umask": "secure"
},
"HealthCheck": {
"Test": [],
"Interval": 0,
"Timeout": 0,
"StartPeriod": 0,
"Retries": 0,
"ExitOnUnhealthy": false
}
},
"NetworkSettings": {
"IPAddress": ""
}
}
]
Querying Information About All Containers
Description
To query information about all containers, run the isula ps command.
Usage
isula ps [OPTIONS]
Parameters
The following table lists the parameters supported by the ps command.
Table 1 Parameter description
Example
Query information about all containers.
$ isula ps -a
ID IMAGE STATUS PID COMMAND EXIT_CODE RESTART_COUNT STARTAT FINISHAT RUNTIME NAMES
e84660aa059c rnd-dockerhub.huawei.com/official/busybox running 304765 "sh" 0 0 13 minutes ago - lcr e84660aa059cafb0a77a4002e65cc9186949132b8e57b7f4d76aa22f28fde016
$ isula ps -a --format "table {{.ID}} {{.Image}}" --no-trunc
ID IMAGE
e84660aa059cafb0a77a4002e65cc9186949132b8e57b7f4d76aa22f28fde016 rnd-dockerhub.huawei.com/official/busybox
Restarting a Container
Description
To restart one or more containers, run the isula restart command.
Usage
isula restart [OPTIONS] CONTAINER [CONTAINER...]
Parameters
The following table lists the parameters supported by the restart command.
Table 1 Parameter description
Time for graceful stop. If the time exceeds the value of this parameter, the container is forcibly stopped. |
Constraints
If the t parameter is specified and the value of t is less than 0, ensure that the application in the container can process the stop signal.
The restart command first calls the stop command to stop the container. Send the SIGTERM signal to the container, and then wait for a period of time (t entered by the user). If the container is still running after the period of time, the SIGKILL signal is sent to forcibly kill the container.
The meaning of the input parameter t is as follows:
t < 0: Wait for graceful stop. This setting is preferred when users are assured that their applications have a proper stop signal processing mechanism.
t = 0: Do not wait and send kill -9 to the container immediately.
t > 0: Wait for a specified period and send kill -9 to the container if the container does not stop within the specified period.
Therefore, if t is set to a value less than 0 (for example, t = -1), ensure that the container application correctly processes the SIGTERM signal. If the container ignores this signal, the container will be suspended when the isula stop command is run.
Example
Restart a container.
$ isula restart c75284634beeede3ab86c828790b439d16b6ed8a537550456b1f94eb852c1c0a
c75284634beeede3ab86c828790b439d16b6ed8a537550456b1f94eb852c1c0a
Waiting for a Container to Exit
Description
To wait for one or more containers to exit, run the isula wait command. Only containers whose runtime is of the LCR type are supported.
Usage
isula wait [OPTIONS] CONTAINER [CONTAINER...]
Parameters
The following table lists the parameters supported by the wait command.
Table 1 Parameter description
Blocks until the container stops and displays the exit code. |
Example
Wait for a single container to exit.
$ isula wait c75284634beeede3ab86c828790b439d16b6ed8a537550456b1f94eb852c1c0a
137
Viewing Process Information in a Container
Description
To view process information in a container, run the isula top command. Only containers whose runtime is of the LCR type are supported.
Usage
isula top [OPTIONS] container [ps options]
Parameters
The following table lists the parameters supported by the top command.
Table 1 Parameter description
Example
Query process information in a container.
$ isula top 21fac8bb9ea8e0be4313c8acea765c8b4798b7d06e043bbab99fc20efa72629c
UID PID PPID C STIME TTY TIME CMD
root 22166 22163 0 23:04 pts/1 00:00:00 sh
Displaying Resource Usage Statistics of a Container
Description
To display resource usage statistics in real time, run the isula stats command. Only containers whose runtime is of the LCR type are supported.
Usage
isula stats [OPTIONS] [CONTAINER...]
Parameters
The following table lists the parameters supported by the stats command.
Table 1 Parameter description
Displays all containers. (By default, only running containers are displayed.) | ||
Display the first result only. Only statistics in non-stream mode are displayed. |
Example
Display resource usage statistics.
$ isula stats --no-stream 21fac8bb9ea8e0be4313c8acea765c8b4798b7d06e043bbab99fc20efa72629c CONTAINER CPU % MEM USAGE / LIMIT MEM % BLOCK I / O PIDS
21fac8bb9ea8 0.00 56.00 KiB / 7.45 GiB 0.00 0.00 B / 0.00 B 1
Obtaining Container Logs
Description
To obtain container logs, run the isula logs command. Only containers whose runtime is of the LCR type are supported.
Usage
isula logs [OPTIONS] [CONTAINER...]
Parameters
The following table lists the parameters supported by the logs command.
Table 1 Parameter description
Constraints
- By default, the container log function is enabled. To disable this function, run the isula create --log-opt disable-log=true or isula run --log-opt disable-log=true command.
Example
Obtain container logs.
$ isula logs 6a144695f5dae81e22700a8a78fac28b19f8bf40e8827568b3329c7d4f742406
hello, world
hello, world
hello, world
Copying Data Between a Container and a Host
Description
To copy data between a host and a container, run the isula cp command. Only containers whose runtime is of the LCR type are supported.
Usage
isula cp [OPTIONS] CONTAINER:SRC_PATH DEST_PATH
isula cp [OPTIONS] SRC_PATH CONTAINER:DEST_PATH
Parameters
The following table lists the parameters supported by the cp command.
Table 1 Parameter description
Constraints
When iSulad copies files, note that the /etc/hostname, /etc/resolv.conf, and /etc/hosts files are not mounted to the host, neither the --volume and --mount parameters. Therefore, the original files in the image instead of the files in the real container are copied.
[root@localhost tmp]# isula cp b330e9be717a:/etc/hostname /tmp/hostname [root@localhost tmp]# cat /tmp/hostname [root@localhost tmp]#
When decompressing a file, iSulad does not check the type of the file or folder to be overwritten in the file system. Instead, iSulad directly overwrites the file or folder. Therefore, if the source is a folder, the file with the same name is forcibly overwritten as a folder. If the source file is a file, the folder with the same name will be forcibly overwritten as a file.
[root@localhost tmp]# rm -rf /tmp/test_file_to_dir && mkdir /tmp/test_file_to_dir [root@localhost tmp]# isula exec b330e9be717a /bin/sh -c "rm -rf /tmp/test_file_to_dir && touch /tmp/test_file_to_dir" [root@localhost tmp]# isula cp b330e9be717a:/tmp/test_file_to_dir /tmp [root@localhost tmp]# ls -al /tmp | grep test_file_to_dir -rw-r----- 1 root root 0 Apr 26 09:59 test_file_to_dir
iSulad freezes the container during the copy process and restores the container after the copy is complete.
Example
Copy the /test/host directory on the host to the /test directory on container 21fac8bb9ea8.
isula cp /test/host 21fac8bb9ea8:/test
Copy the /www directory on container 21fac8bb9ea8 to the /tmp directory on the host.
isula cp 21fac8bb9ea8:/www /tmp/
Pausing a Container
Description
To pause all processes in a container, run the isula pause command. Only containers whose runtime is of the LCR type are supported.
Usage
isula pause CONTAINER [CONTAINER...]
Parameters
Constraints
- Only containers in the running state can be paused.
- After a container is paused, other lifecycle management operations (such as restart, exec, attach, kill, stop, and rm) cannot be performed.
- After a container with health check configurations is paused, the container status changes to unhealthy.
Example
Pause a running container.
$ isula pause 8fe25506fb5883b74c2457f453a960d1ae27a24ee45cdd78fb7426d2022a8bac
8fe25506fb5883b74c2457f453a960d1ae27a24ee45cdd78fb7426d2022a8bac
Resuming a Container
Description
To resume all processes in a container, run the isula unpause command. It is the reverse process of isula pause. Only containers whose runtime is of the LCR type are supported.
Usage
isula unpause CONTAINER [CONTAINER...]
Parameters
Constraints
- Only containers in the paused state can be unpaused.
Example
Resume a paused container.
$ isula unpause 8fe25506fb5883b74c2457f453a960d1ae27a24ee45cdd78fb7426d2022a8bac
8fe25506fb5883b74c2457f453a960d1ae27a24ee45cdd78fb7426d2022a8bac
Obtaining Event Messages from the Server in Real Time
Description
The isula events command is used to obtain event messages such as container image lifecycle and running event from the server in real time. Only containers whose runtime type is lcr are supported.
Usage
isula events [OPTIONS]
Parameter
Example
Run the following command to obtain event messages from the server in real time:
$ isula events