Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 451193 - System hangs at "Starting system message bus:"
Summary: System hangs at "Starting system message bus:"
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: dbus
Version: 4.6
Hardware: i386
OS: Linux
low
urgent
Target Milestone: rc
: ---
Assignee: David Zeuthen
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-13 11:32 UTC by Dag Wieers
Modified: 2013-03-06 03:56 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 16:08:33 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Dag Wieers 2008-06-13 11:32:34 UTC
Description of problem:
We have a similar issue as reported in #186527, #242089 and as mentioned in
knowledgebase article:

    http://kbase.redhat.com/faq/FAQ_85_12494.shtm

During boot the dbus service stalls at:

    Starting system message bus:

The fix mentioned in those articles work for the udev service, but not for the
dbus service. I straced and ltraced dbus-daemon-1 and the application stalls at:

    memcpy(0x8d38a38, "/root", 5)                    = 0x8d38a38
    malloc(12)                                       = 0x8d38998
    __errno_location()                               = 0xb7f196a0
    __strtol_internal("haldaemon", 0xbfe20108, 0)    = 0
    calloc(24, 1)                                    = 0x8d37a40
    getpwnam("haldaemon")                            = 0x252078
    malloc(10)                                       = 0x8d38d40
    memcpy(0x8d38d40, "haldaemon", 10)               = 0x8d38d40
    malloc(2)                                        = 0x8d38980
    memcpy(0x8d38980, "/", 2)                        = 0x8d38980
    malloc(68)                                       = 0x8d37180
    getgrouplist(0x8d38d40, 68, 0x8d37180, 0xbfe20138, 98496

The configuration and setup used at this customer is such that they distribute
passwd and group files, but do the pasword verification and group-lookups via
LDAP. That means that /etc/nsswitch.conf looks like this:

    passwd:     files
    shadow:     files ldap
    group:      files ldap

This used to work fine on 4.5 and earlier distributions, but only with 4.6 and
when LDAP is not accessible the system hangs on boot. This obviously is
unacceptable behaviour.

We tried to add options like bind_timeout and nss_reconnect_ parameters to
ldap.conf without much help. The fact that there is no exhastive information on
what can go into ldap.conf does not help either.

Any help regarding this would be welcome. We are going to open an internal
ticket for this as well.

Version-Release number of selected component (if applicable):
dbus-0.22-12.EL.9
nss_ldap-226-20

How reproducible:
Everytime if LDAP is unreachable (usually during load of system the network
switch configuration is not finished yet. This blocks any other progress until
the network has been configured to get to LDAP.

Comment 1 Dag Wieers 2008-06-18 14:49:48 UTC
Solution from Red Hat support is inside:

    http://rhn.redhat.com/errata/RHBA-2008-0231.html

as part of package:

    nss_ldap-226-24.el4_6.i386.rpm
    nss_ldap-226-24.el4_6.x86_64.rpm

However I cannot set the resolution.

Comment 2 Jiri Pallich 2012-06-20 16:08:33 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.


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