Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 985732

Summary: [RFE] sssd service restart fails when reconfigured too quickly - provide way to display status
Product: Red Hat Enterprise Linux 7 Reporter: David Spurek <dspurek>
Component: sssdAssignee: SSSD Maintainers <sssd-maint>
Status: CLOSED DUPLICATE QA Contact: Kaushik Banerjee <kbanerje>
Severity: high Docs Contact:
Priority: medium    
Version: 7.0CC: dsulliva, grajaiya, jgalipea, jhrozek, joallen, mkosek, pbrezina, pkis
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-23 09:06:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1044717, 1113520, 1133060    

Description David Spurek 2013-07-18 06:14:27 UTC
Description of problem:
Frequently called realm permit causes that sssd service start fails.
I found this problem in test scripts where are realm permit commands called frequently.

I think that sssd service should run or realm permit should inform user about this situation at least.

Version-Release number of selected component (if applicable):
realmd-0.14.2-3.el7.x86_64
sssd-1.10.0-18.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1.realm permit <user>
2.realm permit <user2>
3.realm permit --withdraw <user2>
4.service sssd status

Actual results:
start of sssd service fail

Expected results:
sssd should run or inform user at least

Additional info:
Here is output of my test script:
:: [   PASS   ] :: Running 'realm permit --realm=security.baseos.qe "bender.qe"'
:: [   PASS   ] :: Running 'realm permit --realm=security.baseos.qe "amy.qe"'
realm_list.log
  login-policy: allow-permitted-logins
:: [   PASS   ] :: File 'realm_list.log' should contain 'login-policy:.*allow-permitted-logins'
  permitted-logins: bender.qe, amy.qe
:: [   PASS   ] :: File 'realm_list.log' should contain 'permitted-logins:.*bender.qe, amy.qe'
access_provider = simple
:: [   PASS   ] :: File '/etc/sssd/sssd.conf' should contain 'access_provider = simple'
simple_allow_users = bender, amy
:: [   PASS   ] :: File '/etc/sssd/sssd.conf' should contain 'simple_allow_users = bender, amy'
:: [ 01:36:56 ] ::  Permit --withdraw domain user bender
:: [   PASS   ] :: Running 'realm permit --realm=security.baseos.qe --withdraw "bender.qe"'
realm_list.log
  permitted-logins: amy.qe
:: [   PASS   ] :: File 'realm_list.log' should contain 'permitted-logins:.*amy.qe'
access_provider = simple
:: [   PASS   ] :: File '/etc/sssd/sssd.conf' should contain 'access_provider = simple'
simple_allow_users = amy
:: [   PASS   ] :: File '/etc/sssd/sssd.conf' should contain 'simple_allow_users = amy'


[test]service sssd status
Redirecting to /bin/systemctl status  sssd.service
sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
   Active: failed (Result: start-limit) since Thu 2013-07-18 01:36:56 EDT; 2min 10s ago
  Process: 3524 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS)
 Main PID: 3525 (code=exited, status=0/SUCCESS)
   CGroup: name=systemd:/system/sssd.service

Jul 18 01:36:56 amd-dinar-01.security.baseos.qe systemd[1]: Started System Security Services Daemon.
Jul 18 01:36:56 amd-dinar-01.security.baseos.qe systemd[1]: Stopping System Security Services Daemon...
Jul 18 01:36:56 amd-dinar-01.security.baseos.qe sssd[be[3526]: Shutting down
Jul 18 01:36:56 amd-dinar-01.security.baseos.qe systemd[1]: Starting System Security Services Daemon...
Jul 18 01:36:56 amd-dinar-01.security.baseos.qe systemd[1]: sssd.service start request repeated too quickly, refusing to start.
Jul 18 01:36:56 amd-dinar-01.security.baseos.qe systemd[1]: Failed to start System Security Services Daemon.
Jul 18 01:36:56 amd-dinar-01.security.baseos.qe systemd[1]: Unit sssd.service entered failed state.
Jul 18 01:36:56 amd-dinar-01.security.baseos.qe systemd[1]: Starting System Security Services Daemon...
Jul 18 01:36:56 amd-dinar-01.security.baseos.qe systemd[1]: sssd.service start request repeated too quickly, refusing to start.
Jul 18 01:36:56 amd-dinar-01.security.baseos.qe systemd[1]: Failed to start System Security Services Daemon.

Comment 2 Stef Walter 2013-07-18 07:01:51 UTC
Jakub, is there a better way to tell sssd to reload its config than to restart it? It seems like systemd doesn't like rapid restarts of sssd.

Comment 3 Jakub Hrozek 2013-07-18 07:52:05 UTC
(In reply to Stef Walter from comment #2)
> Jakub, is there a better way to tell sssd to reload its config than to
> restart it? It seems like systemd doesn't like rapid restarts of sssd.

Currently there is not. We had this possibility a long time ago where the SSSD could re-read its config after receiving SIGHUP, but it was fragile and nobody seemed to be interested.

Maybe we could have a lightweight version of the dynamic re-reading that would only check new access control parameters.

I wonder if there is a real use-case, though or whether this is mostly useful in unit tests..

Comment 4 Patrik Kis 2013-07-18 09:01:12 UTC
The real use case is questionable, but I think realmd should at least check the status of the restarted service and return an error if it failed to properly restart such a key service as sssd.

Comment 5 Stef Walter 2013-07-22 12:45:33 UTC
sssd provides no tool to restart the sssd daemon. We use the systemctl command. systemctl merely sends a signal to systemd to restart the service.

We have no way of knowing:

 a) Whether systemd allowed the service to restart
 b) If sssd initialized correctly
 c) If sssd went online correctly

I would love realmd to be able to have more interaction with the startup and status of sssd. However currently sssd provides no such interface. It's a black box in that respect.

Reassigning, and interested in discussing further about how sssd could provide some of the needed interfaces for this sort of thing.

Comment 6 Jakub Hrozek 2013-07-25 10:24:26 UTC
(In reply to Stef Walter from comment #5)
> sssd provides no tool to restart the sssd daemon. We use the systemctl
> command. systemctl merely sends a signal to systemd to restart the service.
> 
> We have no way of knowing:
> 
>  a) Whether systemd allowed the service to restart

This should be handled by systemctl, in particular the error code it returns. I'm not sure SSSD has a way of knowing either..

>  b) If sssd initialized correctly

Current versions of the SSSD wait until the responders and back ends start (or not). Then you can inspect the systemctl return code as well. I just tested by configuring a bogus "id_provider" value.

Maybe we could hint more verbosly into the syslog/journal/whatever?

>  c) If sssd went online correctly
> 

Right, this is a separate issue that we avoided for quite some time, but it's coming up again and again, so it sounds like we might want to do at least some best-effort fix. I would prefer to go with a status tool (see below).

> I would love realmd to be able to have more interaction with the startup and
> status of sssd. However currently sssd provides no such interface. It's a
> black box in that respect.
> 
> Reassigning, and interested in discussing further about how sssd could
> provide some of the needed interfaces for this sort of thing.

In general, I think we need to prioritize work on something like the "sssctl" tool we talked about a while ago. Some kind of richer interface towards the SSSD that would allow to query the status of back ends, what back ends started etc.

There is some discussion summarized in this upstream ticket:
https://fedorahosted.org/sssd/ticket/1828

Comment 7 Jakub Hrozek 2013-08-01 09:07:16 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/385

Comment 13 Kaushik Banerjee 2015-04-23 09:06:37 UTC
This issue is now tracked in bug 879333

*** This bug has been marked as a duplicate of bug 879333 ***