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: stackoverflow.com/questions/4681067/…
    – baptx
    Jul 23 '19 at 18:08
  • This can also be caused by referencing a user that doesn't exist. Mar 19 '20 at 1:12

11 Answers 11


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

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

ExecStart=/bin/echo hello


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:

  • 1
    Thanks. In my case the name was completely wrong, and this solves this problem for me very nicely
    – Aleks
    Apr 13 '18 at 1: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? Nov 22 '18 at 6:36

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

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


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

  • 1
    I had a typo in Group parameter value. Once I fixed the group, it started to work. Jun 5 '20 at 9:20

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

I deleted:


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:


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.


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

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

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


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


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.


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


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)

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.


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


So I checked the bootup time usage with

systemd-analyze blame

Choose the latest one or add below works for me.

New contributor
beyond_st is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • 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.
    – Community Bot
    15 hours ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.