OS X 10.4.7- Not Without Issues

Apple released the OS X update last night bringing the system to version 10.4.7.  Normally I wait a couple of days and let others flush out any problems.  This is time test advice but this time I failed to follow it.  It turns out that, while 10.4.7 does fix a number of issues, it also introduced one big one.

After installing the system update, my MacBook’s processor usage ran solid at 50% on each core.  You didn’t read that wrong… starting right after boot, my processors jumped to 50% load and stayed there!  At first I assumed that Apple has made a change to a subsystem like Spotlight and guessed that my system was re-indexing its files.  But when the system was still working hard two hours later I decided to investigate.

Checking both Activity Monitor and top from the command line, I saw that no process was taking up more than 1% of my processor.  That conflicted with the processor usage graphs I was seeing in both Activity Monitor and MenuMeters.  And judging by the racket the MacBook’s fans were making, I considered the processor graphs more accurate than the process lists.

I asked a friend if he had heard of any issues.  After he finished scolding me for being “that guy” (the first to install any system update), he told me he would keep an eye out for reports.  That night, I returned home to a message on my answering machine.  He had a good suggestion, but not something I would have thought of on my own.  He reported that someone posted a similar issue and disabling the Windows Sharing service in the Sharing Preference Pane might solve the problem.

I gave it a try, and sure enough!  As soon as I disabled the service, my Mac stopped having a conniption.  As I prepared the post for the site, I did some more research.  This thread from Apple’s Support Forum came up and spelled it all out for me.  I was not the only one experiencing the issue.

If you look down through the thread, EBL was able to attribute the issue to the SMB service.  He also realized that massive log files were being created as a result.  Another user explained that his log file had already accumulated 5GB of data!  Checking mine, I found the log file to be a hefty 882MB.  To check yours, simply enter this into the terminal window: ls –lah /var/log/samba and hit return.  Look at the size of the file named log.nmbd.  To kill the painfully large log file, simply enter sudo rm -f /var/log/smb/log.nmbd into the terminal window and hit return.  In the case of both commands, you will need to enter the admin password to complete the process.

This brings an important question to mind.  If a good handful of savvy users have actually noticed the problem, how many users out there are experiencing it and are simply unaware that their systems are working overtime?  I consider myself something of a freak when it comes to knowing what is happening on my system.  I use MenuMeters to display my memory, processor, and network stats on the screen at all times.  Most people would have to notice the fans in their machines are running loud, or simply that their performance has gone to hell.  I’m not sure the symptoms are immediately evident to an average user.

Granted, this particular issue will only affect users who have the Windows Sharing service active.  Still, I use that feature on a daily basis.  Odds are other users do too!

It seems Apple has some issues to resolve with 10.4.7.  And with one of the issues causing this much trouble, I think we can expect another update shortly.  But, as another friend recently reminded me, the worst day on the Mac is still far better than a good day with Windows.

Update: 7/1/06 9:45am
It’s worth noting that my old G4 tower did not have issues after upgrading to 10.4.7… even with Windows Sharing enabled.


(Visited 5,006 times, 1 visits today)
3 Responses to OS X 10.4.7- Not Without Issues
  1. Anonymous Reply

    How can I download the Windows 9? It says it’s downloading but it’s not.

  2. Steve Reply


  3. Reg. Charney Reply

    I detected the same problem when I ran out of disk space. My log.nmbd file was 40G+. Interesting enough, none of the normal OS X utilities, like GetInfo told me this.

    I needed to go to the command line and issue a series of “sudo du -hc -d 0 /private/*” and follow the trail to find that the file was under /private/var/log/samba.

    BTW, I also have Windows sharing turned sudo du -hc -d 0 /private/var/log/samba/* as a regular environment.

    Finally, I found the correct path for deleting the file is “sudo rm -f /private/var/log/samba/log.nmbd” (One of the previous posts talked about “sudo -f /vart/log/smb/log.nmbd”).

Leave a Reply

Your email address will not be published. Please enter your name, email and a comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed.