7 Integration with SystemD
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
- Advantages of using journald as logging driver and events back end
- Podman and SystemD managing containerized services lifecycle 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 service, which you would want SystemD to manage. A SystemD.socket is another kind of unit file which SystemD uses and is covered in section 7.6. The SystemD service unit files are one way you can share your containerized service with the world. As you see in figure 7.1 Podman's fork-exec model grants SystemD ability to track the processes within a containerized service.