RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1445093 - Error '217/USER' When Attempting To Run Systemd Service As A Non-Local User.
Summary: Error '217/USER' When Attempting To Run Systemd Service As A Non-Local User.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.4
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL: https://www.freedesktop.org/software/...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-24 22:28 UTC by Bernie Hoefer
Modified: 2023-09-14 03:56 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-20 20:05:36 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Bernie Hoefer 2017-04-24 22:28:30 UTC 
Description of problem:

When a user attempts to use a non-local user (i.e. one not found in /etc/passwd, but instead in LDAP or Active Directory) to run a systemd-controlled service, it fails.  

One sees the following in the output of "systemctl status ${SERVICE_NAME}".  (In the below customer example, this is "configapiSelfService.service".)


configapiSelfService.service - configapi Self Service API service
   Loaded: loaded (/etc/systemd/system/configapiSelfService.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2017-04-13 14:00:46 CDT; 4 days ago
  Process: 1203 ExecStart=/home/jenkins/scripts/startconfigapiSelfService.sh (code=exited, status=217/USER)

Apr 13 14:00:46 server.example.com systemd[1]: Starting configapi Self Service API service...
Apr 13 14:00:46 server.example.com systemd[1203]: Failed at step USER spawning /home/jenkins/scripts/startconfigapiSelfSe...ocess
Apr 13 14:00:46 server.example.com systemd[1]: configapiSelfService.service: control process exited, code=exited status=217
Apr 13 14:00:46 server.example.com systemd[1]: Failed to start configapi Self Service API service.
Apr 13 14:00:46 server.example.com systemd[1]: Unit configapiSelfService.service entered failed state.
Apr 13 14:00:46 server.example.com systemd[1]: configapiSelfService.service failed


Here is the service.unit file used in the attempt:


[Unit]
Description=configapi Self Service API service
After=network.target

[Service]
User=jenkins
Type=forking
ExecStart=/home/jenkins/scripts/startconfigapiSelfService.sh
ExecStop=/home/jenkins/scripts/stopconfigapiSelfService.sh

[Install]
WantedBy=multi-user.target



Version-Release number of selected component (if applicable):

systemd-219-30.el7_3.7.x86_64



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>
Comment 2 Lukáš Nykrýn 2017-04-25 08:00:02 UTC 
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
Comment 3 Lukáš Nykrýn 2017-04-25 08:10:42 UTC 
> 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.
Comment 4 Bernie Hoefer 2017-04-25 12:41:36 UTC 
(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.
Comment 5 Venkata Tadimarri 2017-04-27 01:38:20 UTC 
   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.
Comment 6 Lukáš Nykrýn 2017-04-27 07:04:17 UTC 
Huh? Why do you set a non-local user for sssd, which is intended to provide access to non-local users?
Comment 7 Venkata Tadimarri 2017-04-27 07:09:53 UTC 
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.
Comment 10 Kyle Walker 2019-06-20 20:05:36 UTC 
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.
Comment 11 Red Hat Bugzilla 2023-09-14 03:56:56 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
Note You need to log in before you can comment on or make changes to this bug.