Bug 431301 - dbus-daemon-1 (/etc/init.d/messagebus) hangs up during boot process
Summary: dbus-daemon-1 (/etc/init.d/messagebus) hangs up during boot process
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: dbus   
(Show other bugs)
Version: 4.6
Hardware: i686 Linux
Target Milestone: rc
: ---
Assignee: David Zeuthen
QA Contact: desktop-bugs@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2008-02-02 11:34 UTC by Eijiro Sumii
Modified: 2013-03-06 03:54 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-20 16:03:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Eijiro Sumii 2008-02-02 11:34:40 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv: Gecko/20071127 Firefox/

Description of problem:
The system fails to boot because "/etc/init.d/messagebus start" hangs up during the boot process.

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

How reproducible:

Steps to Reproduce:
1. Set up LDAP _without_ nscd.
2. Reboot the system.

Actual Results:
System hangs up and doesn't boot.

Expected Results:
System should boot.

Additional info:
Also reported in #429702 as a part of another problem (about nscd)

Comment 1 Eijiro Sumii 2008-02-02 14:02:55 UTC
P.S.  This is _not_ related to other reports that are talking about various
cases where the ldap server is _not_ running.  In our case, the ldap server is
already running well without any problem.

Comment 2 Eijiro Sumii 2008-03-10 05:50:36 UTC
OK, downgrading nss_ldap from nss_ldap-226-20 to nss_ldap-226-18 solved the
problem, so it seems to be a problem of nss_ldap rather than dbus.

Comment 3 Jose Plans 2008-03-10 06:17:39 UTC
Hi Elijiro,
was this hung happening (in 226-20) using nss_initgroups_ignoreusers in

Comment 5 Eijiro Sumii 2008-03-10 06:23:32 UTC
Yes, my /etc/ldap.conf has the following line:

nss_initgroups_ignoreusers root,ldap

Comment 6 Jose Plans 2008-03-10 06:40:46 UTC
Then it sounds like Bug 429101 which reported a lock not cleared when using that
option, this could cause getgrouplist() or others(to confirm) to lockup from
threaded apps such as nscd or dbus-daemon-1. It's planned to be fixed on 4.7.
One way to see if this is the same bug is to comment out that option and see if
the system boots back or if dbus can be started.
Or you could see if the process is actually locked at mutex_lock_wait.

Comment 7 Eijiro Sumii 2008-03-10 06:57:16 UTC
I see, I cannot access Bug 429101 but yes, commenting out
nss_initgroups_ignoreusers (with nss_ldap-226-20) also solved this issue for me.
 (I will keep nss_ldap-226-18, though, because of Bug 427189.)  Thanks!

Comment 8 Paul Howarth 2008-04-16 17:47:10 UTC
Commenting out nss_initgroups_ignoreusers fixed this for me too.

It had been stuck on futex before doing this:

open("/etc/passwd", O_RDONLY)           = 4
fcntl64(4, F_GETFD)                     = 0
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=2078, ...}) = 0
read(4, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 2078
close(4)                                = 0
munmap(0xb7f2d000, 4096)                = 0
open("/etc/group", O_RDONLY)            = 4
fcntl64(4, F_GETFD)                     = 0
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=742, ...}) = 0
_llseek(4, 0, [0], SEEK_CUR)            = 0
read(4, "root:x:0:root\nbin:x:1:root,bin,d"..., 4096) = 742
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0xb7f2d000, 4096)                = 0
futex(0x53b568, FUTEX_WAIT, 2, NULL 

Comment 9 Jiri Pallich 2012-06-20 16:03:43 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.