This error most likely occurs during startups and is usually caused by errors or missing parameters in the service unit configuration. In my case, the service provided by a vendor, let's call it 'fancy.service', was misconfigured out of the box which led to these errors in the system's journal:
[root@server ~]# journalctl
...
Jun 21 20:02:54 server.example.com systemd[992]: fancy.service: Failed to determine user credentials: No such process
Jun 21 20:02:54 server.example.com systemd[992]: fancy.service: Failed at step USER spawning /usr/bin/sh: No such process
...
The root cause was the order in which the services were started. This 'fancy.service' didn't have any 'Wants=' or 'After=' declared although it required having network (network.target) access and being able to authenticate users (sssd.service), so let's fix that. First, create the overrides-directory for the service and add the required settings to a '.conf'-file:
[root@server ~]# mkdir /etc/systemd/system/fancy.service.d
[root@server ~]# cat << EOF >> /etc/systemd/system/fancy.service.d/overrides-unit.conf
[Unit]
After=network.target sssd.service
Wants=sssd.service
EOF
Now to test the changes, reboot the server:
[root@server ~]# systemctl reboot
After the reboot, the service started as expected in my case.
Feel free to comment and / or suggest a topic.
Comments
Post a Comment