Red Hat Bugzilla – Bug 142301
mDNSResponder goes into uninterruptible sleep on suspend-resume
Last modified: 2007-11-30 17:10:56 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
On a laptop system using ACPI, the mDNSResponder daemon frequently
goes into a state where it shows up top in "uninterruptible sleep"
state signified by "D" in the S column. This seems to occur when the
laptop has suspended and resumed, and once it occurs the system will
no longer suspend, and mDNSResponder cannot be killed. The laptop
is being suspended using the "mem" method of /sys/power/state.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot the system running mDNSResponder
2. Suspend the system repeatedly
Actual Results: The system will fail to suspend giving an error
message about mDNSResponder. The init script will not be able to stop
mDNSResponder. Kill will not work on mDNSResponder. mDNSResponder
shows up in a process list as in "uninterruptible sleep" state.
Expected Results: The system should suspend cleanly, and
mDNSResponder should shutdown when killed.
This really sounds like a kernel issue. Processes in D state are
waiting in the kernel for some device-related issue. All
mDNSResponder does is send and receive ip broadcasts and talk to
clients over unix domain sockets.
Yes. I filed it under howl because that is where the bug manifests,
and included the kernel version in the report.
I see this problem as well, and it currently occurs for me with kernel
2.6.10-1.741_FC3. The first thing that happens for me is that I
attempt to suspend the computer, and mDNSResponder does not stop, and
the system is not suspended.
If I kill mDNSResponder before suspending, or stop it from starting, I
see no problems. It may be a kernel issue, but mDNSResponder is
certainly the trigger.
I get the same issue, running on 2.6.10-1.741_FC3 on a Thinkpad T21
laptop. Once this happens, there's no killing the mDNSResponder
process ("service mDNSResponder stop" doesn't work.) The only
solution I've found is to reboot.
I think there is a way to find out where in the kernel the process is
blocking. Can anyone try to figure that out and report back here?
This bug has been fixed in Fedora Core 4.
I no longer see this problem, and as far as I am concerned the bug can be closed.