Recently I stumbled upon an issue when I tried to setup a custom service (daemon) inside a Docker container, and I couldn't find anything that could help me yet.

Here is the situation: I have a file custom.service, where all the settings of the service are set (by the way, the service works perfectly on the host). Then I move the service file to /etc/systemd/system/ directory, where all the service files are stored. After moving the file I have to run the systemctl daemon-reload command to add the service to system service list (re-index the folder, in a way), but that's where the issue happens.

Apparently there is no systemctl in Docker, therefore I am unable to execute the needed command and add the service to the system service list. Running service custom start says custom: unrecognized service which means that the service wasn't added to the system properly.

I am quite sure that someone had the same issue, but Google didn't help me yet. Maybe you know how to fix that, or maybe there are some alternatives to this command?

1 Answer 1


If you want to use a systemd unit inside a container, you need to install systemd in the container and ensure that it’s the first process; for example, here’s how to run Apache httpd controlled by systemd:

FROM fedora:33
ENV container docker
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
CMD [ "/sbin/init" ]

You’ll also need to ensure a number of volumes are present:

docker run -d --tmpfs /tmp --tmpfs /run -v /sys/fs/cgroup:/sys/fs/cgroup:ro httpd

(assuming your built image is named httpd).

See Running systemd in a non-privileged container for details, or How to run systemd in a container for a simpler approach using Podman.

You might find it simpler to rework your container to not use a systemd unit.

  • Hi, Stephen! I feel like adding the systemd to the container is quite unnecessary, since I just need to add the custom service to the system list. From the forums and different articles I understood that systemd was stripped from docker images for a reason, and adding it back is not the best idea. The thing is, I am running a web app inside a container, which also needs a custom and simple background daemon for async DB updates. One thing that separates me from running the daemon properly is adding it to a system services list, so I can start it with service custom start.
    – hancack
    Apr 27, 2021 at 1:05
  • Basically I need to do the same thing that systemctl daemon-reload does, but without actual systemd in the system. I just thought that maybe I can add systemd to the container, run the command, and when the service will be added is it should be, remove systemd to keep the container lighter and isolated. What do you think about this approach?
    – hancack
    Apr 27, 2021 at 1:08
  • When you write “adding it to a system services list”, which list of services do you mean? The container’s, or really the system’s? Do you want to be able to run service custom start from the container, or from the host? Apr 27, 2021 at 5:14
  • I wanna run the service inside the container, since the web app is there. Therefore the service custom start command should be ran inside the container as well. About adding service to the system services list - here is what I mean: after adding the custom.service file to the /etc/systemd/system/ folder I have run systemctl daemon-reload, which updates the system so service command can see it, otherwise the service is invisible to the service command. So I need to make the service command see my custom daemon. I really hope that makes sense :))
    – hancack
    Apr 27, 2021 at 15:11
  • So you want to run the container, and from within the container, inform systemd outside the container about a service inside the container, and use systemd outside the container to start the service inside the container? That’s... not going to end well (it’s doable, but rather complicated). Apr 27, 2021 at 15:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .