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