This chapter covers
- Running systemd within the container as the primary process
- Generating systemd unit files from existing containers
- Socket-activated containerized services
- Using sd-notify containerized services
- The advantages of using journald as a logging driver and events backend
- Using Podman and systemd to manage containerized services’ life cycles on edge devices
Systemd is the de facto init system for Linux. Almost every distribution of Linux defaults to systemd as the first process launched after the kernel, which then launches all of the services, including the login sessions for the user. Podman embraces the power of systemd and uses it for starting up lots of its services. When starting containerized services at boot time, Podman encourages users to use systemd unit files with Podman commands. Unit files are what systemd calls its configuration files. Systemd supports a few different types of unit files, including service files in which you can define a service, which you would want systemd to manage. A SystemD.socket is another kind of unit file systemd uses (see section 7.6). The systemd service unit files are a way to share your containerized service with the world. As you see in figure 7.1, Podman’s fork/exec model grants systemd the ability to track the processes within a containerized service.
