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 1110369 - sssd is started before messagebus, making sssd-ifp fail
Summary: sssd is started before messagebus, making sssd-ifp fail
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-17 13:53 UTC by Jan Pazdziora
Modified: 2020-05-02 17:44 UTC (History)
10 users (show)

Fixed In Version: sssd-1.11.6-3.el6
Doc Type: Bug Fix
Doc Text:
No Documentation Needed
Clone Of:
Environment:
Last Closed: 2014-10-14 04:48:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 3402 0 None None None 2020-05-02 17:44:07 UTC
Red Hat Product Errata RHBA-2014:1375 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2014-10-14 01:06:25 UTC

Description Jan Pazdziora 2014-06-17 13:53:15 UTC
Description of problem:

The /etc/init.d/sssd defines

   # chkconfig: - 12 88

and /etc/init.d/messagebus defines

   # chkconfig: 345 22 85

making dbus start after sssd. If the ifp is enabled, it will be stopped immediately during boot or init 3 because dbus is not yet running.

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

# rpm -qf /etc/init.d/sssd /etc/init.d/messagebus 
sssd-common-1.11.6-1.el6.x86_64
dbus-1.2.24-7.el6_3.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. Have IPA-enrolled machine or otherwise get sssd configured and enabled.
2. Check that chkconfig --list | grep -E 'messagebus|sssd' lists both as on.
3. Add ifp to services list in [sssd] section in /etc/sssd/sssd.conf.
4. Run tail -f /var/log/sssd/sssd.log & to see what is going on.
5. Run service messagebus stop ; service sssd stop ; init 3
6. Check if sssd_ifp is running: ps axuw | grep ifp

Actual results:

Stopping system message bus: [  OK  ]
Stopping sssd: [  OK  ]
(Tue Jun 17 09:50:00 2014) [sssd] [mt_svc_exit_handler] (0x0010): Process [ifp], definitely stopped!

No ifp process.

Expected results:

No error message, sssd_ifp still running:

root     16070  0.0  0.0 199860  2916 ?        S    09:50   0:00 /usr/libexec/sssd/sssd_ifp --debug-to-files

Additional info:

One possibility is to change the order but maybe messagebus wants sssd to be running?

Another possibility is for sssd_ifp not bail out when it does not find dbus running.

Yes another possibility is to somehow start sssd in stages -- first the non-dbus stuff, and then after dbus is up the dbus part.

Comment 3 Jan Pazdziora 2014-06-17 13:56:40 UTC
The issue can likely be also observed by rebooting the machine.

Comment 4 Jakub Hrozek 2014-06-17 14:11:31 UTC
We're debating the right solution with the DBus developers. So far, one option that came up was making SSSD poll for the system bus:
https://fedorahosted.org/sssd/ticket/2360

Comment 5 Jan Pazdziora 2014-06-17 14:19:36 UTC
The problem with polling is, if you have fast machine, httpd could be started before the next poll and attempt to serve request and dbus call will fail.

Polling is good to recover from some errors but for consistent boot sequence, it might be good to also have an explicit chkconfig entry after messagebus but before things like httpd to poke sssd to retry right away. HUP or USR1, maybe?

Comment 6 Jakub Hrozek 2014-06-18 13:48:31 UTC
Stef, do you know of any DBus service that is in the same area as SSSD, that is, both an identity provider and a DBus service?

I wish we could simply put a watch on the DBus system bus socket and only start the IFP service then, but inotify can't watch for nonexistent files (obvisously).

Comment 7 Jakub Hrozek 2014-06-18 14:09:14 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2360

Comment 8 Jakub Hrozek 2014-06-19 15:17:35 UTC
I talked to Marius a bit today on IRC and he had an interesting suggestion a bit along the lines of what Jan suggested in comment #5.

The proposal was to let DBus (not an initscript entry) start a simple binary that would SIGHUP the sssd and let it know it's time to spawn the dbus service. I'll try to experiment with this and start a thread on sssd-devel.

btw the reason I don't like simply starting messagebus before sssd is that sssd users might be included in places like the interface policy XML. Clearly dbus consumes identities at that point, so the identities should be resolvable.

Comment 9 Stef Walter 2014-06-20 07:07:54 UTC
(In reply to Jakub Hrozek from comment #8)
> I talked to Marius a bit today on IRC and he had an interesting suggestion a
> bit along the lines of what Jan suggested in comment #5.
> 
> The proposal was to let DBus (not an initscript entry) start a simple binary
> that would SIGHUP the sssd and let it know it's time to spawn the dbus
> service. I'll try to experiment with this and start a thread on sssd-devel.

Yes, not a bad idea. Although you could use any other means of communication, such as the usual sssd unix sockets as well.

Comment 10 Jakub Hrozek 2014-06-25 13:18:06 UTC
Hi Jan,

given that sssd-dbus is mostly used by Satellite in RHEL6, would the Sat QE be available to help with testing?

Comment 14 Jakub Hrozek 2014-06-29 10:06:57 UTC
Patches are available for review on the upstream sssd-devel list.

Comment 18 Jakub Hrozek 2014-07-21 10:10:49 UTC
Just for reference, here are the commits that fixed the bug:


* master:
    1a59af8245f183f22d87d067a90197d8e2ea958d
    1746e8b8399da2a7a8da4aace186f66055ccfec1
    149f40dc2d4ead57811c70b5028648ac83f6a1a7
    b76419cf8830440b46c20a15585562343c7b1924
    0c1d65998907930678da2d091789446f2c344d5d
    1f2507e1fd089f2bf3458cfb4faeaa9669d72f98
    4df1a6a977df74420867d9b1daddcca0eea4b2e1 

* sssd-1-11:
    80af7e9daed52b283af037864bcdd86d96695618
    42b0c3442815c0374735377c7f5ced4fe1a00e97
    87d3c7d23885b0b6dca3d7cf0494c7b93225429c
    fbc3f000ca0672bb18797201768bd13e5611eaad
    3e57c78c8163f6ee395bdf34b1e2c550cd8467f1
    727f4bf4829f2405c978a4c9b960bef3ad86b002
    906177a2666bf360a3d85fec55fc942cf9b33163

Comment 19 Kaushik Banerjee 2014-09-10 09:32:15 UTC
Verified with version 1.11.6-29.el6

# chkconfig --list | grep -E 'messagebus|sssd'
messagebus     	0:off	1:off	2:on	3:on	4:on	5:on	6:off
sssd           	0:off	1:off	2:off	3:on	4:on	5:on	6:off

service messagebus stop ; service sssd stop ; init 3

# ps axuw | grep ifp
root     13135  0.0  0.3 199972  3368 ?        S    05:29   0:00 /usr/libexec/sssd/sssd_ifp --debug-to-files

Comment 20 errata-xmlrpc 2014-10-14 04:48:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1375.html


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