what causes “systemd: Failed at step USER spawning /usr/sbin/opendkim: No such process”

Question

How can I remove following error:

systemd: Failed at step USER spawning /usr/sbin/opendkim: No such process

It occurs when I try to start opendkim service on Centos.

I got this error because I entered the wrong user and group. On Debian, it worked with the user `nobody` and the group `nogroup`: https://stackoverflow.com/questions/4681067/how-do-i-run-a-node-js-application-as-its-own-process/28542093#28542093 — baptx, Jul 23 '19 at 18:08
This can also be caused by referencing a user that doesn't exist. — James Mills, Mar 19 '20 at 01:12

score 42 · Answer 1 · answered Jul 18 '17 at 14:12

42

I've just ran into this and in my case it was caused by quoting a user name in my service file:

[Unit]
Description=Demonstrate Failed at step USER spawning ...: No such process error when user name is quoted

[Service]
User="tadeusz"
ExecStart=/bin/echo hello

[Install]
WantedBy=multi-user.target

Starting this service on Ubuntu 16.04.2 LTS (Amazon EC2 instance) would fail with following error:

user-example.service: Failed at step USER spawning /bin/echo: No such process

Interestingly, on Ubuntu Gnome 17.04 (my local machine), the error message is much more helpful:

[/etc/systemd/system/user-example.service:5] Invalid user/group name or numeric ID, ignoring: "tadeusz"

Removing quotes in both environments resolved the problem:

[Service]
User=tadeusz

answered Jul 18 '17 at 14:12

Tad Lispy

851
1
8
11

2

Thanks. In my case the name was completely wrong, and this solves this problem for me very nicely – Aleks Apr 13 '18 at 01:06
1

After pulling my hair for long 4 hours I came across this post and just removed `User=tomcat` which I copied from blog post. Now it works fine :) – Shashanth Aug 27 '18 at 10:18
I got similar problem, fixing the username doesn't work, because gunicorn file is not present in virtualenv. I installed using- sudo pip3 install gunicorn in AWS EC2 ubuntu server. what could be possible reason? – Reema Parakh Nov 22 '18 at 06:36

score 9 · Answer 2 · answered Nov 21 '18 at 04:09

9

For me it was a simple issue of using the wrong user name, confirm you are using right user [Service] User=tadeusz

then reload your SytemD sudo systemctl daemon-reload

answered Nov 21 '18 at 04:09

StackEdd

191
1
3

1

I had a typo in Group parameter value. Once I fixed the group, it started to work. – Leos Literak Jun 05 '20 at 09:20

score 6 · Answer 3 · edited Dec 28 '16 at 14:53

6

Check if the following record exists in the configuration file of opendkim:

## Attempt to become the specified user before starting operations. UserID opendkim:opendkim

edited Dec 28 '16 at 14:53

Kamil Maciorowski

69,815
22
136
202

answered Dec 28 '16 at 06:04

user679441

61
1

score 5 · Answer 4 · answered Mar 03 '19 at 01:38

5

In my case I tried to use root as the User and Group.

I deleted:

User=root
Group=root

answered Mar 03 '19 at 01:38

jmunsch

279
4
8

rogerdpack · Answer 5 · 2022-01-11T18:23:30.647

For me with that error message, turns out I was specifying "User=root" but not "Group=xx", so when I specified both it fixed it:

User=root
Group=root

so either adding Group=root or getting rid of both User= and Group=, as suggested in jmunsch's answer, fixed it. There was some kind of directory permission issue without specifying Group.

I guess if you specify a User then it doesn't use the default Group, which I presume is also root? Though the default is supposed to be User=root and the default group is supposed to be that user's default group, so not sure if this is expected.

It is also helpful, regardless the message, to check journalctl for any logs or any indications of what might have gone wrong. If it's "217/USER" then it won't show much in there for diagnosing but for everything else it can have super helpful info.

score 2 · Answer 6 · answered Mar 01 '22 at 07:38

2

This can happen for user related problems obviously.

What's unobvious is that this may also happen sometimes when systemd is upgraded. To solve it, either reboot the system, or re-execute systemd with the following command:

systemctl daemon-reexec

answered Mar 01 '22 at 07:38

pallxk

324
1
5

score 1 · Answer 7 · answered Jan 20 '22 at 02:11

1

Same situation with @rogerdpack, all we need is waiting enough time for AD ready. But there is no luck for me on

After=vasd.service 
After=mnt-share.mount 
After=nss-user-lookup.target

So I checked the bootup time usage with

systemd-analyze blame

Choose the latest one or add below works for me.

After=multi-user.target

answered Jan 20 '22 at 02:11

beyond_st

11
1

Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Jan 20 '22 at 06:15

Babken Vardanyan · Answer 8 · 2018-08-18T16:16:20.203

0

For me this error message was caused by not reloading SystemD after updating systemd. So run # systemctl daemon-reload or reboot your computer.

edited Aug 18 '18 at 16:16

answered Aug 15 '18 at 15:02

Babken Vardanyan

1,543
2
15
15

1

`sudo systemctl daemon-reload` should be enough – dvska Aug 17 '18 at 15:40

score 0 · Answer 9 · answered Dec 12 '20 at 13:25

0

For me it was solved by commenting "User" and "Group" directives in the service file as described here. I hope it helps somebody.

answered Dec 12 '20 at 13:25

crvio

1

score 0 · Answer 10 · answered Dec 05 '21 at 08:14

In my case I've been getting the error when using

DynamicUser=yes

It turns out that my version of systemd is too old. From https://0pointer.net/blog/dynamic-users-with-systemd.html:

... we released systemd 235. Among other improvements this greatly extends the dynamic user logic of systemd. Dynamic users are a powerful but little known concept, supported in its basic form since systemd 232. With this blog story I hope to make it a bit better known.

rogerdpack · Answer 11 · 2022-01-11T18:46:51.507

Ran into this message, but only at boot time, starting it manually it started fine.

My hunch is that it was caused by "active directory" (where this particular box gets some of its usernames and groups) not having been fully initiated yet, so adding a

After=vasd.service

Seems to have fixed it by making it start late enough. After=mnt-share.mount also seemed to work around the problem, but I think possibly because it just happened to "also wait long enough" or something. Or After=nss-user-lookup.target https://systemd.io/UIDS-GIDS/

systemctl status xxx said:

Failed at spawning... [?]
Process: 5017 ExecStart=/home/user/bin/xx (code=exited, status=217/USER)

score 0 · Answer 12 · answered Jan 12 '22 at 09:55

0

I had the same error message which was caused by an invalid WorkingDirectory=/does/not/exist entry. This caused spawning the process to fail because the work directory did not exist.

answered Jan 12 '22 at 09:55

Simon A. Eugster

930
1
9
16

what causes “systemd: Failed at step USER spawning /usr/sbin/opendkim: No such process”

12 Answers12

Linked