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'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? – Reema Parakh 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


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

I deleted:


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 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


Turns out I was specifying "User=root" but not Group, 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. It was some kind of directory permission issue without specifyiing Group.

I guess if you specify a User then it doesn't use the default Group, which I presume is also root? Kind of makes sense...

Update, ran into this again, unrelated, 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 "wait long enough" or something.

systemctl status xxx said:

Process: 5017 ExecStart=/home/user/bin/xx (code=exited, status=217/USER)

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.

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.