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.
13 Answers
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
-
2Thanks. In my case the name was completely wrong, and this solves this problem for me very nicely– AleksCommented Apr 13, 2018 at 1:06
-
1After pulling my hair for long 4 hours I came across this post and just removed
User=tomcatwhich I copied from blog post. Now it works fine :) Commented Aug 27, 2018 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? Commented Nov 22, 2018 at 6:36
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
-
1I had a typo in Group parameter value. Once I fixed the group, it started to work. Commented Jun 5, 2020 at 9:20
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:
User=root
Group=root
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.
answered Jun 24, 2019 at 15:25
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
-
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 BotCommented Jan 20, 2022 at 6:15
-
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
In my case the problem was because of invalid line separator in a executable .sh-file. But there is a list of possible problems:
- file does not exists
- file is not executable
- can't access file (invalid rights)
- invalid line separator
- file path is not absolute
- and some others
For me this error message was caused by not reloading SystemD after updating systemd. So run # systemctl daemon-reload or reboot your computer.
answered Aug 15, 2018 at 15:02
-
1
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
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.
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)
answered Jan 11, 2022 at 18:27
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, 2022 at 9:55
nobodyand the groupnogroup: stackoverflow.com/questions/4681067/…