From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 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): howl-0.9.6-6 kernel-2.6.9-1.681_FC3 How reproducible: Sometimes 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.