systemd apparently not finding .service file

Question

I've put together a foo.service file for our foo service that runs as a daemon. The service runs fine when I run systemctl start foo (and stop) but systemtcl enable foo results in Failed to issue method call: Invalid argument. The unit file is placed in /etc/systemd/system/foo.service, and has permissions 0755. Setting systemd to debug and running enable gives

Looking for unit files in (highest priority first):`
    /etc/systemd/system
    /run/systemd/system
    /usr/local/lib/systemd/system
    /usr/lib/systemd/system
Looking for SysV init scripts in:
    /etc/rc.d/init.d
Looking for SysV rcN.d links in:
    /etc/rd.c
Failed to issue method call: Invalid argument

Googling around, it seems like systemctl isn't finding the .service file. Is there any way to verify that? If so, how can I fix that? Any other ideas about what might be wrong? Is there more debugging I can enable? The debug info given doesn't really help me narrow down the problem.

foo.service looks like:

[Unit]
Description=Blah Blah Blah

[Service]
ExecStart=/usr/bar/doof/foo
Type=simple
PIDFile=/var/run/foo.pid

[Install]
WantedBy=multi-user.target,graphical.target

EDIT: Yes, I did run systemctl daemon-reload.

Have you ran `systemctl daemon-reload` after adding or changing your foo.service file ? — nos, Dec 28 '15 at 22:26

score 99 · Accepted Answer · answered Dec 24 '16 at 21:06

99

For people from Google:

Validate with sudo systemd-analyze verify NAME.service
When using a symlink, make sure it uses absolute path
Make sure the name is like /etc/systemd/system/*.service
Do sudo systemctl daemon-reload after changes

answered Dec 24 '16 at 21:06

Mark

18,730
7
107
130

6

For me, I was doing soft link (`ln -s ... ...`). I did hard link (`ln ... ...`) and it worked – Anand Undavia Apr 15 '19 at 11:35
2

@AnandUndavia You should be getting an error: `*.service is not a symlink, ignoring.` when using a hard link. – Jonathan Komar Apr 23 '19 at 11:25
`sudo systemd-analyze verify xxx` gave me `Unknown operation 'verify'` – Pierre de LESPINAY Apr 28 '22 at 06:37
@PierredeLESPINAY As of v248 it's still in the manual, but if you find the cause / workaround please edit it into the answer! – Mark Apr 28 '22 at 18:59
I got `Unit foo.service not found` when lookup the foo daemon, even when I specified the absolute path, would it be that it is recognised by the `systemctl` with another name? – jimmymcheung Sep 22 '22 at 11:05

score 25 · Answer 2 · edited Apr 14 '22 at 12:32

The issue in my case was the file was symlinked from another partition and systemd do not support that.

Unit files have to reside on a partition that is mounted at the moment the host PID 1 is invoked. i.e. either on the root partition or some other partition that the initrd premounts.

I'm answering to an old question because this is a top result while googling on the issue and might help someone

score 22 · Answer 3 · answered Feb 04 '22 at 20:24

22

I found this question over google, searching for "systemctl unit not found"

In my case I generated a *.service file via podman and no matter what I did, systemctl wouldn't find the service file.

Solution was to check selinux and set the correct labels. Example:

/sbin/restorecon -v /etc/systemd/system/container_httpd.service

answered Feb 04 '22 at 20:24

N02291

251
2
4

2

Thank you! This did it for me. Can you elaborate what exactly it does? – Niwla23 Dec 25 '22 at 13:09
good solution, indeed the podman generate is an issue – TecHunter May 08 '23 at 11:10
@Niwla23 Selinux restricts `systemd` to only seeing files labelled `systemd_unit_file_t`. The service file in question was created elsewhere (usually generated by `podman-generate`) and then moved here. Since moving a file does not update its label, this file keeps its original (different) label that was assigned when it was created, and therefore cannot be seen by `systemd`. `restorecon` resets the file context according to the persistent rules at `/etc/selinux/targeted/contexts/files`, which "corrects" the label. – cyqsimon Jul 11 '23 at 19:22

Asad-ullah Khan · Answer 4 · 2022-10-24T16:30:38.823

7

Make sure that if you are putting your units in the user folder .config/systemd/user/*.service that you are running the command as

systemd --user <command>

(note the --user)

edited Oct 24 '22 at 16:30

answered Oct 18 '22 at 19:56

Asad-ullah Khan

1,573
18
22

score 3 · Answer 5 · edited Jul 15 '18 at 00:55

3

Error is because of two target are specified to WantedBy. Just mention in this way:

[Install]
WantedBy=multi-user.target

I really don't know how we can specify two targets to it.

edited Jul 15 '18 at 00:55

slm

15,396
12
109
124

answered Jan 28 '16 at 12:00

ASB

324
1
2
7

5

Multiple targets are space delimited, not comma delimited. – James M. Lay Dec 14 '16 at 05:50
WantedBy option may be used more than once, or a space-separated list of unit names may be given. So this answer is correct. – Pramod Dec 13 '17 at 06:12

erikh · Answer 6 · 2022-09-20T21:47:16.890

2

Had this issue earlier when adding my own units, turned out to be wrong/missing context for SELinux. Test again with setenforce permissive set and set proper context for SELinux with chcon when in enforcing mode.

edited Sep 20 '22 at 21:47

answered Sep 20 '22 at 21:43

erikh

21
3

This solved the problem for me on Oracle OCI VM instance. – Alexander Apr 03 '23 at 07:37

Nick Lauder · Answer 7 · 2022-03-24T10:20:13.863

I ran into this error when using Podman to generate systemd unit files.

The error occurred because selinux was blocking the file from being properly read. I found there were two solutions.

Set your directory to the systemd service location for unit files with cd /etc/systemd/system. Then use podman generate to create the file directly here. This seems to be accepted by selinux without issue.
Generate the systemd unit file with podman generate and copy the file to /etc/systemd/system. You then need to run /sbin/restorecon -v /etc/systemd/system/container-<your container name>.service to have selinux reset its security context for that file.

score 0 · Answer 8 · answered Jan 19 '23 at 18:11

When you run into this you can try to get the file it refers to. For example, I had the same problem with ContainerD. All I had to do was go to another server and get the file "cat /lib/systemd/system/containerd.service". Somewhere on your file system, this file has to exist (maybe in your backups).

systemd apparently not finding .service file

8 Answers8