Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Recover from a runaway netstat process System
For quite a while now, my G5 has been exhibiting an occasional odd problem on wake from sleep: both CPUs usage meters are pegged (which I can see in a split second, thanks to the MenuMeters graph in the menubar). When I look at top -u 10 in the Terminal, I see that a process named netstat is sucking up nearly 100% of both CPUs. A quick man netstat shows that this really isn't a process that should be continuously running: "The netstat command symbolically displays the contents of various network-related data structures."

The hint for solving the problem is simple: just kill the process. However, since it's owned by root, you'll need to do so with root powers, i.e. sudo killall netstat. As soon as the process is killed, CPU usage goes back to normal, and the netstat process doesn't spontaneously restart ... except when I again wake from sleep (but only sometimes).

I have no idea what's causing the problem, but the solution is relatively painless ... and it turns out that I'm not alone in my troubles; there's a two-page discussion on this very subject over on our forum site. The issue might be related to non-standard entries in /etc/hosts, or related only to G5s, though nothing has been proven at this point. Please feel free to add to the thread on the forums if you have any insights; the comments here are not intended to help troubleshoot the issue -- that's why we have a forum site :).
    •    
  • Currently 1.67 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (3 votes cast)
 
[7,652 views]  

Recover from a runaway netstat process | 14 comments | Create New Account
Click here to return to the 'Recover from a runaway netstat process' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Recover from a runaway netstat process
Authored by: geohar on Aug 23, '04 01:26:21PM

is it possible that it's menumeters itself that's spawning netstat?



[ Reply to This | # ]
Recover from a runaway netstat process
Authored by: TvE on Aug 23, '04 01:35:02PM

I guess so - but sofar I haven't had any problems with MM



[ Reply to This | # ]
Recover from a runaway netstat process
Authored by: gourls on Aug 23, '04 02:14:56PM

That is kind of weird that a CPU would just do that. Ok, it's REALLY weird. I have never heard of anything like that. Sounds like it's going to be all right.



[ Reply to This | # ]
Recover from a runaway netstat process
Authored by: susfour on Aug 23, '04 02:31:19PM

I have a classic app (quickbooks) that maxes the CPU every time it's run. I've never been able to determine why or cause it to stop. Quitting the app makes cpu usage go back to normal.



[ Reply to This | # ]
Recover from a runaway netstat process
Authored by: randalla on Aug 23, '04 03:48:38PM

Many Classic apps do this just by how they were written. I have the same issue with FileMaker Pro 4 when run under Classic.



[ Reply to This | # ]
Recover from a runaway netstat process
Authored by: geohar on Aug 23, '04 04:02:32PM

Classic Apps that do this are written with a polling event model which rapidly checks if any event from the OS is pending, and sits there in a tight loop checking until such an event occurs. Unfortunately, the tight loop is pretty efficient for the CPU to execute and therefore consumes a high percentage of the CPU.

Modern even models on Mac OS work in such a way that the OS will not schedule the app until there is an event pending, and they therefore don't take CPU doing so. Additionally, they can be paged out totally until an event occurs.



[ Reply to This | # ]
Recover from a runaway netstat process
Authored by: jiclark on Aug 23, '04 02:20:54PM

I doubt Menu Meters is causiing it, as I don't use that utility and I've been experiencing the problem for some time. The non-Terminal way to kill netstat is to use Activity Monitor, choose All Processes from the popup, click on the %CPU column heading to force netstat to the top of the list, then just select netstat and hit the Quit Process button at the top of the window. You'll be prompted for your admin password to complete the job.

Good luck,
John



[ Reply to This | # ]
Recover from a runaway netstat process
Authored by: MattHaffner on Aug 23, '04 03:06:00PM

There was also a GeekTool hint that had a nice netstat output in it to show open ports. Be careful with these though--they can be resource hungry. By default netstat tries to reverse map all the IP numbers in its output. You can stop this by adding '-n' to the command line.

It's possible that netstat could be hanging or at least stalling if the DNS server isn't available (like wireless goes out of range, wake from sleep before network is fully up, etc.). If you have a frequently running netstat that's trying to resolve names, you could be taking a noticeable hit on performance. Although it's nice to know what's going on all the time, I put an open port monitor in a GeekTool subset and only turn it on if I am currently interested in that info.



[ Reply to This | # ]
Recover from a runaway netstat process
Authored by: MattHaffner on Aug 23, '04 03:11:38PM

One other tip to help find out who spawned off the netstat originally:

Open the Activity Monitor and double-click on the netstat process that's sucking up CPU. In the window that pops up, the 'Parent Process' field should be helpful to trace where the command started from. You can even click on the parent process and follow the chain of commands further back.

From the terminal, 'ps' can give you this information as well with the 'l' listing option. The PPID field has the parent process ID. Of course you have to do the tracing back by hand in that case, but it's very scriptable then.



[ Reply to This | # ]
netstat is from the set-hostname script
Authored by: hayne on Aug 23, '04 07:36:25PM

One of the people who have been struggling with this issue in the forums had discovered that the errant 'netstat' process was started from a script named 'set-hostname' which was started via 'configd'. See the forum thread for more details. I have just added a summary there:
http://forums.macosxhints.com/showthread.php?t=23485



[ Reply to This | # ]
Recover from a runaway netstat process
Authored by: srh on Aug 23, '04 03:12:48PM

Another possibility is to try 'pstree' (via fink) and find out what process
is starting the netstat process.



[ Reply to This | # ]
parent process id
Authored by: sjk on Aug 23, '04 07:15:34PM

Or add "-o ppid" to the ps command line.



[ Reply to This | # ]
Recover from a runaway netstat process
Authored by: frankko on Aug 23, '04 03:40:40PM

I was able to prevent the netstat process from going out of control [most of the time] by unchecking the "wake for ethernet network administrator access" option in Energy Saver.

Sometimes it will still happen, but not every time I wake my machine from sleep like it used to.

Also, I don't know if anybody has noticed (or if it even matters), but whenever this happened on my G5, even though netstat was running, a new entry for netstat was created in my Crash log directory.



[ Reply to This | # ]
Recover from a runaway netstat process
Authored by: Makosuke on Aug 23, '04 06:07:46PM

I agree that the easiest way to kill the thing is Activity monitor; since I always have the floating bars in the corner of the screen (which is how I ususally notice that netstat has gone berserk again), it's only a couple of clicks to bring up the process list and kill netstat (requires an admin password, but nothing more).

As for why, the thread here had more info than the time I brought it up on MacFixIt and the Apple forums, but no more than I've figured out myself.

What is known is that there's a background process that's trying to call netstat and do something with its output, but netstat goes berserk and stalls, using 100% of a processor untill somebody manually kills it. (Interestingly, if you run netstat via the Network Utility GUI, you can see the same infinite loop of errors for yourself. This doesn't happen right after startup, only after the computer's been on for a while.)

Some Linux mailing lists mentioned that having networking components out of synch with the kernel can cause a similar problem, but that's all I've come up with for theories as to why.

There may be multiple variations of this problem, but at least in my personal explorations I've found no consistent factors other than people with dual processor G5s with 2GB or more of RAM, who used the "upgrade" option when installing 10.3 over 10.2.x.



[ Reply to This | # ]