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:
[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:
Check if the following record exists in the configuration file of
## Attempt to become the specified user before starting operations.
In my case I tried to use
root as the User and Group.
For me this error message was caused by not reloading SystemD after updating systemd. So run
# systemctl daemon-reload or reboot your computer.
For me it was a simple issue of using the wrong user name, confirm you are using right user
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.