Bug 1445093

Can you please try to add
After=nss-user-lookup.target

https://www.freedesktop.org/software/systemd/man/systemd.special.html#nss-user-lookup.target

> Additional info:
> 
> A customer and a senior support engineer claims this was fixed in Fedora in
> this BZ:
> 
> <https://bugzilla.redhat.com/show_bug.cgi?id=915912>

This patch should be already in rhel.

(In reply to Lukáš Nykrýn from comment #2)
===
> Can you please try to add
> After=nss-user-lookup.target
===

I will do this and let you know whether that fixes the issue for the customer.  Thank you.

   Active: failed (Result: exit-code) since Thu 2017-04-27 09:19:27 CST; 28s ago
  Process: 24278 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=217/USER)
 Main PID: 24193 (code=exited, status=0/SUCCESS)

Apr 27 09:19:27 ipa72ad.adipatrust.com systemd[1]: Starting System Security Services Daemon...
Apr 27 09:19:27 ipa72ad.adipatrust.com systemd[1]: sssd.service: control process exited, code=exited status=217
Apr 27 09:19:27 ipa72ad.adipatrust.com systemd[1]: Failed to start System Security Services Daemon.
Apr 27 09:19:27 ipa72ad.adipatrust.com systemd[1]: Unit sssd.service entered failed state.
Apr 27 09:19:27 ipa72ad.adipatrust.com systemd[1]: sssd.service failed.



I still get the same issue. 



This is my unit file


[Unit]
Description=System Security Services Daemon
# SSSD must be running before we permit user sessions
Before=systemd-user-sessions.service nss-user-lookup.target
Wants=nss-user-lookup.target
After=nss-user-lookup.target

[Service]
User=ktadimar
EnvironmentFile=-/etc/sysconfig/sssd
ExecStart=/usr/sbin/sssd -D -f
# These two should be used with traditional UNIX forking daemons
# consult systemd.service(5) for more details
Type=forking
PIDFile=/var/run/sssd.pid

[Install]
WantedBy=multi-user.target


Here is what I did..


Ad user

[root@ipa72ad system]# id ktadimar
uid=114601274(ktadimar) gid=114601274(ktadimar) groups=114601274(ktadimar),114601309(testgroup),114601304(sssdtest5),114600513(domain users),114601307(sssdtestnew),114600512(domain admins)


Edit the unit file with User and After details. 

[root@ipa72ad system]# vi sssd.service
[root@ipa72ad system]# systemctl daemon-reload

Restart the sssd service.

[root@ipa72ad system]# systemctl restart sssd
Job for sssd.service failed because the control process exited with error code. See "systemctl status sssd.service" and "journalctl -xe" for details.
[root@ipa72ad system]# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/sssd.service.d
           └─journal.conf
   Active: failed (Result: exit-code) since Thu 2017-04-27 09:37:01 CST; 5s ago
  Process: 25065 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=8)
 Main PID: 24990 (code=exited, status=0/SUCCESS)

Apr 27 09:37:01 ipa72ad.adipatrust.com systemd[1]: Starting System Security Services Daemon...
Apr 27 09:37:01 ipa72ad.adipatrust.com systemd[1]: sssd.service: control process exited, code=exited status=8
Apr 27 09:37:01 ipa72ad.adipatrust.com systemd[1]: Failed to start System Security Services Daemon.
Apr 27 09:37:01 ipa72ad.adipatrust.com systemd[1]: Unit sssd.service entered failed state.
Apr 27 09:37:01 ipa72ad.adipatrust.com systemd[1]: sssd.service failed.

Huh? Why do you set a non-local user for sssd, which is intended to provide access to non-local users?

I am assuming that the issue is with any service and not just a custom service. I didnt have the reproducer and hence tried with a service randomly. Let me try another user.

Due to the originating case being closed for an extended period of time, and no further reports of this behaviour, I am closing this bug at this time in order to focus our efforts on higher priority issues. It is recommended that any service that requires a user that is handled by a backing LDAP implementation (or similar) to have the following included in the Unit file definition:

    Wants=nss-user-lookup.target
    After=nss-user-lookup.target


This being said, it is notable that system-level users (typically UID below 1000) are assumed to be local. This has been documented in the following:

    https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/system_administrators_guide/index#sec-Managing_User_Accounts

From the above:

System accounts are presumed to be available locally on a system. If these accounts are configured and provided remotely, such as in the instance of an LDAP configuration, system breakage and service start failures can occur.


For services that reference non-local users (that are not part of the above restriction), the above "nss-user-lookup.target" mechanism can be used. If there is a specific service that is found to fail due to a similar condition, and the above configuration doesn't result in it functioning properly, please reopen if a further occurrence is encountered.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days