System's init and Container's COMMAND/Dockerfile's CMD

# System's init and Container's COMMAND/Dockerfile's CMD ###### tags: `Linux`, `init`, `Container`, `Dockerfile`, `CMD`, `ENTRYPOINT`, `Podman`, `docker` I gave [Launch the First Process in Linux System](https://www.slideshare.net/chienhungpan/launch-the-first-process-in-linux-system/chienhungpan/launch-the-first-process-in-linux-system) as a talk in [COSCUP 2022](https://coscup.org/2022/en/session/AGCMDJ). <iframe src="//www.slideshare.net/slideshow/embed_code/key/MS7tHmn7tA8ESv" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/chienhungpan/launch-the-first-process-in-linux-system" title="Launch the First Process in Linux System" target="_blank">Launch the First Process in Linux System</a> </strong> from <strong><a href="//www.slideshare.net/chienhungpan" target="_blank">Jian-Hong Pan</a></strong> </div> ## From System The **init** application in the **file system** is the **first process** brought up by the kernel. It can be any executable application, even a shell script. The init application: * can be a link, for example: ```shell $ ls -l /sbin/init lrwxrwxrwx 1 root root 22 7月 13 22:24 /sbin/init -> ../lib/systemd/systemd ``` * can be an exact executable file You can also tell kernel where is the application in the **file system** to be the **init** process by appending `init=` as a [parameter](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html) into kernel's boot command. Here, we mentioned the **init** process, the **first process** and the **file system** above. ## From Container * [podman run](https://docs.podman.io/en/latest/markdown/podman-run.1.html): > *Run a process in a new container. podman run starts a process with its own file system, its own networking, and its own isolated process tree. The image which starts the process may define defaults related to the process that will be run in the container, the networking to expose, and more, but podman run gives final control to the operator or administrator who starts the container from the image.* * [docker run](https://docs.docker.com/engine/reference/commandline/run/): > *Run a command in a new container. > ... > The docker run command first creates a writeable container layer over the specified image, and then starts it using the specified command.* * Dockerfile's [CMD](https://docs.docker.com/engine/reference/builder/#cmd): > *The main purpose of a `CMD` is to provide defaults for an executing container. > ... > If the user specifies arguments to `docker run` then they will override the default specified in `CMD`.* Also, refer to [ENTRYPOINT](https://docs.docker.com/engine/reference/builder/#entrypoint): > *An `ENTRYPOINT` allows you to configure a container that will run as an executable.* A container will run an application from its file system. The application is defined in the Dockerfile's `CMD`/`ENTRYPOINT`, or the container run command's `COMMAND`. So, the application is the **first process** executed by the container. And, the application must be in the container's **file system**. Here, we mentioned **first process** and the **file system** above. ## Conclusion Both sytem and container run an application in the **file system** as the **first process**. After that, they have the same idea basically. The difference: * System: The **kernel** runs the **init** as the first process. * Container: The **container** runs the **COMMAND** mapping to the application as the first process. The container runs and depends on the system. The container does use **[`chroot`](https://linux.die.net/man/1/chroot)** technology to have the target root directory as the **file system** and the **COMMAND**, actually.