This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 985732 - [RFE] sssd service restart fails when reconfigured too quickly - provide way to display status
[RFE] sssd service restart fails when reconfigured too quickly - provide way ...
Status: CLOSED DUPLICATE of bug 879333
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd (Show other bugs)
7.0
Unspecified Unspecified
medium Severity high
: rc
: ---
Assigned To: SSSD Maintainers
Kaushik Banerjee
: FutureFeature
Depends On:
Blocks: 1044717 1113520 1133060
  Show dependency treegraph
 
Reported: 2013-07-18 02:14 EDT by David Spurek
Modified: 2015-04-23 05:06 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-04-23 05:06:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Spurek 2013-07-18 02:14:27 EDT
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@security.baseos.qe"'
:: [   PASS   ] :: Running 'realm permit --realm=security.baseos.qe "amy@security.baseos.qe"'
realm_list.log
  login-policy: allow-permitted-logins
:: [   PASS   ] :: File 'realm_list.log' should contain 'login-policy:.*allow-permitted-logins'
  permitted-logins: bender@security.baseos.qe, amy@security.baseos.qe
:: [   PASS   ] :: File 'realm_list.log' should contain 'permitted-logins:.*bender@security.baseos.qe, amy@security.baseos.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@security.baseos.qe"'
realm_list.log
  permitted-logins: amy@security.baseos.qe
:: [   PASS   ] :: File 'realm_list.log' should contain 'permitted-logins:.*amy@security.baseos.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 03:01:51 EDT
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 03:52:05 EDT
(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 05:01:12 EDT
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 08:45:33 EDT
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 06:24:26 EDT
(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 05:07:16 EDT
Upstream ticket:
https://fedorahosted.org/sssd/ticket/385
Comment 13 Kaushik Banerjee 2015-04-23 05:06:37 EDT
This issue is now tracked in bug 879333

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

Note You need to log in before you can comment on or make changes to this bug.