I have created a systemd service file and placed it in /etc/systemd/system/anfragen-3dkonfig-mapper.service. I ran systemctl daemon-reload, systemctl daemon-reexec and rebooted the system.

  • systemctl enable anfragen-3dkonfig-mapper results in

    Failed to enable unit: Unit file anfragen-3dkonfig-mapper.service does not exist.
  • systemctl start anfragen-3dkonfig-mapper results in

    Failed to start anfragen-3dkonfig-mapper.service: Unit anfragen-3dkonfig-mapper.service not found.
  • ls -lh /etc/systemd/system/anfragen-3dkonfig-mapper.service outputs

    -rw-r--r--. 1 root root 440 Mar 19 12:08 /etc/systemd/system/anfragen-3dkonfig-mapper.service
  • cd /root && systemd-analyze verify anfragen-3dkonfig-mapper.service has an exit code of 0 and prints no output.

  • mount shows

    /dev/sda2 on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
  • There are no other mounts touching /usr or /etc.

  • The contents of the service file are:

    Description=Anfragen 3D Konfigurations Mapper Service
    ExecStartPre=-/usr/bin/podman stop anfragen-3dkonfig-mapper
    ExecStartPre=-/usr/bin/podman rm anfragen-3dkonfig-mapper
    ExecStart=/usr/bin/podman run --rm --name anfragen-3dkonfig-mapper-app -p 10010:10000 anfragen-3dkonfig-mapper-app:0.0.1
    ExecStop=/usr/bin/podman stop anfragen-3dkonfig-mapper
  • All above commands were run as the root user.

  • Operating System: CentOS Linux release 8.0.1905 (Core)
  • Systemd version: 239
  • Linux kernel: Linux version 4.18.0-80.11.2.el8_0.x86_64 ([email protected]) (gcc version 8.2.1 20180905 (Red Hat 8.2.1-3) (GCC))
  • I vaguely remember having a similar problem with another service file some months ago which just magically started working after a few hours of poking around and renaming the service file back and forth.

I'm interested in two things:

  • How does one debug such a problem?
  • What is wrong?
  • are there other .service files there? If you copy one of them is it "detectable" by systemd?
    – rogerdpack
    Commented Mar 19, 2020 at 15:23

4 Answers 4


As hinted at by @JdeBP wrong SELinux file labels are the reason for the behavior. The . character in the output of ls indicates that there is a security context set for the file. So be attentive to the . in the ls output!

cd /etc/systemd/system && ls -lhZ some-other-service.service anfragen-3dkonfig-mapper.service prints

-rw-r--r--. 1 root root unconfined_u:object_r:admin_home_t:s0        440 Mar 19 12:08 anfragen-3dkonfig-mapper.service
-rw-r--r--. 1 root root unconfined_u:object_r:systemd_unit_file_t:s0 457 Feb 24 11:42 some-other-service.service

It can be seen that the other service file has the systemd_unit_file_t label, while the broken service doesn't. This can be fixed with restorecon anfragen-3dkonfig-mapper.service. After this the labels look as follows:

-rw-r--r--. 1 root root unconfined_u:object_r:systemd_unit_file_t:s0 440 Mar 19 12:08 anfragen-3dkonfig-mapper.service
-rw-r--r--. 1 root root unconfined_u:object_r:systemd_unit_file_t:s0 457 Feb 24 11:42 some-other-service.service

systemd now behaves as expected.

  • how does restorecon know how to label the service file correctly? Commented Sep 30, 2021 at 0:44
  • I don't know! You may start a new question about that. Commented Sep 30, 2021 at 12:32
  • How do you modify these headers in a nuanced way? Or is placing the file in the right folder and running restorecon file "The Way" to do it?
    – zrooda
    Commented Oct 8, 2022 at 15:26
  • See chcon. But know what you are doing. A restorecon will just trample over your individual changes. So I guess ideally one should write selinux rule files and then rely on restorecon. Commented Oct 10, 2022 at 8:21

SELinux restrictions are making life complex for you.

  • You were right, SELinux file labels were the problem. Commented Mar 19, 2020 at 16:33
  • Is that only from GNU ls?
    – user232326
    Commented Mar 19, 2020 at 18:23

I just spent an hour chasing this issue after moving some of the service files around. The symlink in /lib/systemd/system was pointing to the correct file, but the symlink in /etc/systemd/system was not (its target no longer existed). I removed this offending (broken) symlink, replaced it with the correct one, and it worked.


Had similar issue, we use rootless podman on centos7.

Container were not started after reboot, the services were not found. But before reboot the services were enabled and present in /etc/systemd/system. Services were created via syslink ln -s from /home/user to /etc/systemd

When you run after reboot Systemctl status nameOfService.service it returns "Unit servicename.service could not be found."

When you run systemctl daemon-reload the service is present again.

One possible solution is to create a syslink ln -s from /root/ to /etc/systemd/system - after reboot your service will still exist.

Better solution

  • Create your own service that executes daemon-reload and starts your service

Create startServiceOnBoot.sh script with daemon-reload and start of your service

    sudo systemctl daemon-reload    
    sudo systemctl start nameOfService.service

Make sh script executable chmod +x startServiecOnBoot.sh

Create your service /etc/systemd/system/serviceStarter.service

Description=Daemon Reloader



Enable service on boot systemctl enable serviceStarter.service you can also check if starting your new service serviceStarter.service actually starts nameOfService.service aswell.

I tried After= and .timer with services in systemd but were not successfull. For debugging $systemd-analyze blame

You must log in to answer this question.

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