I don't have a Fitbit app.
Went over to mom's again this afternoon. As soon as I got there, I noticed that I had the "mdsnd" running away with the CPU time. I turned off WiFi and bluetooth, but did not turn off the mobile data. I then restarted the phone at 3:00 PM to clear the problem. I did not recharge the battery but instead monitored using "Settings" -> "Battery". The CPU total for "mdsnd" was stopped at 34m 46s. It did not change. I later turned on bluetooth and then later turned on WiFi. At first I connected the WiFi to an Xfinity hotspot and then about a 1/2 hour later connected to the encrypted hotspot at my mom's. I even turned off WiFi again and back on letting it auto reconnect to my mom's encrypted hotspot. The CPU time stayed at 34m 46s for a few hours. I'm home now and my CPU time is now 34m 49s. Looks like the problem doesn't reproduce easily without knowing what is going on in the internet. I'm not sure that the problem is necessarily at my mom's environment. Also don't know if it may have tried to connect to some random hotspot along the way to mom's. To be continued.
Did some more checking. Have found that "mdnsd" is indeed related to "mDNSResponder".
Have also found man pages for both:
mdnsd (Linux Reviews)
https://www.daemon-systems.org/man/mdnsd.8.html
and source from apple:
https://opensource.apple.com/source/mDNSResponder/mDNSResponder-214/mDNSCore/mDNS.c
HOWEVER, these are PROBABLY NOT THE VERSIONS BEING USED on the Android. This is just to give me some idea of what this program did on their respective systems. The underlying protocol may not have changed much.
After further looking, the relationship between Firefox and mdnsd or mDNSResponder is wider than just the Android platform. It appears that mdnsd is a daemon, as I had suspected. This means it starts and runs in the background and may not be directly loaded by programs such as Firefox. Programs such as Firefox wake this process up by using internal (to the device) communications between the two processes. The caller program can be any program that wishes to use this service, which is why we see this problem even though we are not running Firefox.
At some point I would like to figure out how to access the system log, if that is possible without running a rooted system. The log may have some further information as to what is happening.
TO BE CONTINUED.
mdnsd is also an implementation of a protocol to discover local devices on the local internet. This is used to among other things discover network connected printers.
For the time being I will see what happens when I disable my network printer that uses HP's printer interface.
Link to some documents about what mdsnd discovers:
https://developer.apple.com/library...ction.html#//apple_ref/doc/uid/TP40002445-SW1
Disabling the printer device in "settings" -> "More setings" -> "Printing" did not make the problem go away.
I am seeing the problem while at my home also.
Doing a "netstat" in the "Terminal Emulator" app when I see the problem, I see many sockets of type "udp" and "udp6" on port 5353 that are in the "CLOSE" state but with several thousand bytes in the "Recv-Q". When things are running normally, I just see a few of these sockets and the Recv-Q is 0. Later, I noticed that as I continued to run even when the mdnsd process was not in a hard loop, the number of the "udp" and "udp6" sockets on port 5353 with CLOSE state and several thousand bytes in the "Recv-Q" grew slowly. It almost appears as if when this growth is unchecked, some resource runs out and "mdnsd" goes into the hard loop failure mode.
This is possibly just another symptom of the problem in that the "mdnsd" process is failing to read its socket in a timely manner.
In my earlier searches, I did see someone compalining about a bad file descriptor error on a select, so this is probably the cause of this large unserviced queue.
Henry
Because of an idea I was trying, I ended up disabling and re-enabling the Verizon Cloud app. This caused the latest version to get loaded. Noticed that it has been changed from what I had. Checking, I found that it had been updated to version 16.5.33 dated Nov 30, 2016. Don't think that this would affect problem, but thought I would record it anyway.