Mac OSX — Stop ’syslogd’ Being A CPU Hog on Blog24

Mac OSX — Stop ’syslogd’ Being A CPU Hog

Posted by Chris
On July 23, 2008
Categories: Apple, Featured, Software

Activity Monitor icon Since Apple released the first major update for Mac OS 10.5 (10.5.1) some users may have experienced a slowing down of their machines which, at first, looks like it’s caused by ‘syslogd‘.

To see if your Mac is suffering with this strange processor hogging problem open Activity Monitor (found in the Utilities folder in Applications). You might see something like the screenshot below which shows syslogd using a large percentage of the processor power.

[click image to enlarge]

The actual cause of the problem is varied but it is not syslogd itself. There have been numerous discussions on Mac OS Hints, Apple Support , Mac Rumors, and other Apple Mac forums, mainly started by users with their pleads for help.

Having noticed the problem many users have searched the system log for clues to what is actually causing syslogd to go haywire. Some concluded that it was Apple’s back up software, Time Machine, while others were having problems with Last.fm software. There is a list of other possible culprits being suggested in the forums.

When I searched for more information about this Mac OSX annoyance I found plenty of descriptions of the symptoms but sadly few solutions. A few people had suggested ways to fix the problem, but none of these seemed to work for me.

One likely solution has been provided by Daniel Simmons, who wrote the article ‘Taming Leopard’s Syslogd‘ on the subject. Unfortunately I did not find this solution until solving the quandary using quite a different method. Try Daniel’s suggestion — it might work for you.

Erroneous Disk Permissions?

I tried starting up from the Leopard install disk and running Disk Utility having been inspired by an article found on PooPsTech WebLog entitled ‘mdworker Slows down OS X - 100% CPU Usage! Here is the solution!‘. However, after running ‘Repair Disk Permissions’ the problem persisted.

Last Resort Fix

Armed with freshly brewed coffee and a book to read I started the process of installing Leopard (Mac OS 10.5.1) from scratch using Archive and Install with the Preserve Users and Network Settings option [see below].

Once the installation process had completed a quick look at the Activity Monitor application showed that syslogd was not hogging the processor. Reinstallation seemed to have done the trick, but, my system had regressed to 10.5.1. With this in mind I downloaded the 10.5.4 all-in-one update to install manually — rather than relying on the operating system’s Software Update.

Apple Mac OS Leopard Installer Application

Archive and Install

Select this option if you want to install a fresh system on your computer. “Archive and Install” moves your existing Mac OS X system files to a folder named Previous System, and then installs a new copy of Mac OS X on the selected volume. Mac OS X–installed applications, such as Address Book and Safari, are archived, and new versions are installed in the Applications folder.

Unless you choose “Preserve Users and Network Settings,” user accounts and their home folders are also archived in the Previous System folder.

Excerpt from Apple Leopard’s Install & Setup Guide

The Moment of Truth

Once the installation process had completed and I had read a considerable portion of the novel I had started I waited for the Mac to start up with optimistic trepidation. Apple’s software was true to its word and kept all additional software and user files in place as well as providing a copy of the old system neatly placed in a new folder named Previous System.

Of course the first application I ran was Activity Monitor and syslogd was not topping the heavy CPU user chart. Using the search field I found that syslogd appeared to be behaving itself and continued to do so when my usual profusion of open apps:

Finally! The problem had be solved. All indicators were, well, indicating that the unwelcome situation had been banished. As I write this a few days after reinstallation of Leopard I can report with glee that this method, although drastic, works.

As previously mentioned this method ought to be treated as a last resort. If you have this problem with your Mac and nothing else works for you then the reinstallation of Leopard will work.

Before Reinstallation…

Be sure to backup your files before any major installation. Time Machine makes it easy and I highly recommend keeping it turned on.

Help From Apple

It is a shame that this strange error does not have an easier fix, and had not been fixed via Apple’s software updates. I am not sure when syslogd started to take up so much processing power. When I first upgraded to Leopard the disc I bought was already version 10.5.1, and let Software Update maintain and update the system. Perhaps that is where the problem lies, hence I downloaded the update direct from the Apple website.

I must admit that I find it annoying that there are no definitive answers and that Apple does not seem to be taking much notice of the discussions about what is causing syslogd to ~~monopolize~~ monopolise the CPU. Although, to be fair to Apple, it is a relatively old and uncommon fault which does not affect new Macs. However, it really ought to be addressed for users of older machines that have older versions of the operating system and are having trouble after updating system software.

Bookmark and Share

Close Bookmark and Share This Page

Save to Browser Favorites / Bookmarks

Email This to a Friend

Copy HTML:

If you like this then please subscribe to the RSS Feed.

7 Responses to “ Mac OSX — Stop ’syslogd’ Being A CPU Hog ”

# 1 Gianni Says:
August 20th, 2008 at 3:49 pm
It could be possible that I hold the key to this problem on my computer, but don’t know where to look exactly.

THE HISTORY OF MY CASE:

Two days ago I was confronted with the syslogd for the first time being a CPU hog (a.k.a. runaway syslogd process). (it also appeared on my Intel 2.2 MacBook running Mac OS 10.5.4 and iTunes 7.7.1). I had never seen the syslogd in the Activity Monitor before, until I plugged in my iPhone, that action caused iTunes to start and had the following chain reaction.

When iTunes stared that day, I happened to be very low on fre disk space. A temporary Volume back up on my internal drive that day left me with about 900 MB of free space. I knew this was a thin line to walk but I it would only be for a short while. However when iTunes launched it started to download several new episodes of weekly podcasts, while I was working on other things, not realizing the size of the podcasts would soon be filling that last 900 MB of free space.

First I got the message that the OS was running low on free space. While finding unimportant files to delete I forgot to pause the iTunes download and it got to filling my last bytes of free space before I cleared any files. Immediately thereafter iTunes showed the message that it could not save the Music Library due to lack of disk space.

A few seconds later the OS message popped up that I had to select a running application for a force quit attempt to continue in the Finder. I was able to quit everyting that was not important to me like Safari, Word, iCal and Toast, but it was already too late. The Finder beach ball appeared and soon everything froze, iTunes, Terminal and Activity Monitor included, after that only a cold reboot holding the power button a few seconds seemed my way out.

After the reboot al seemed fine, I deleted some files to have at least 2 GB of free space. This was still fine until I launched iTunes. iTunes froze up on launch and something unknown began consuming the disk space again, Further analysis showed me about 6 MB per second was being filled. There was no network activity so I was sure it was not a download or something coming from outside. iTunes appeared together with the syslogd taking all the CPU power in the Activity Monitor while the cooling fan of the MacBook reached its maximum noise level.

MY CONCLUSION:

My theory therefore is now that the problem is definitely not the syslogd process itself. This process maybe only responding to a problem caused by any other application (iTunes in my case), maybe syslogd is even trying to solve it. I am lucky that i can prevent iTunes.app from launching and the syslogd in my case will perform normal until I launch iTunes. Other people might have an other application or process they cannot prevent from launching.

The problem is likely related to a damaged or unclosed file left on my drive after the forced reboot with 0 bytes left. Other people might also have a situation with problems caused by a forced reboot or power failure. Since in my case it was obviously related to iTunes, I tried renaming my iTunes Library, with success, iTunes appears normal again (without any music and podcasts), also the syslogd didn’t reappear as CPU hog.

I assume if I put my iTunes Library file back in place, the problem will also be back. So how can I use this fact to help you finding the true cause of the chain reaction? How can I see what iTunes sends to or requests from the syslogd prior to it going haywire? This could hold the key to a general solution of the yet unidentified cause.

G.
# 2 bobby Says:
August 21st, 2008 at 5:35 pm
come on chris, my man. this “fix” sounds like an answer i’d receive from a less than enthusiastic apple tech support agent.

this is NOT a fix.

you are correct in saying it is only used as an almost last resort. last be initializing. but please, title your article differently so i don’t waist my time with the obvious. something like “syslogd, thy cpu hog, fears only the disc OS” or “pity those swyned by the syslogd hog - arch/intsl for all”.

and there’s no need saying that myself, bobby, would knows of this obvious and painful clean-slate method, but some might not so it should be publicized.

they, the peeps who don’t know, will be just as disappointed as i. moreso, you’ll be teaching them about reinstalling as an only answer here and there in the life of a mac. still no “fix”. nobody wants to arch/inst. until mac perfects new system installs with *perfect user set-ups preserved, it remains yuckpuke with a middle finger to the world.

everyone. keep googlein’.
# 3 Chris Says:
August 22nd, 2008 at 1:41 am
Bobby:
Thanks for your input — I totally agree, reinstallation of a whole operating system is NOT a fix.

However, it is one solution to a problem that evidently continues to blight a number of Mac users and it ought to work for everyone, if none of the other methods that are mentioned and linked to in the post work.

In the article the word ‘fix’ only appears once with direct reference to the reinstallation method of ridding OSX of the bug. In the sub-heading that begins ‘Last Resort…’

However, I think I may have found the cause of your wasted time and subsequent dismay. The content within the description meta tag of this page may have been the cause and so I have edited it.

It did read (ambiguously so it would seem):

“How to fix a problem on Mac OSX (10.5.x) that sometimes causes syslogd to hog the CPU.”

Now it reads:

“Links to articles that may fix a problem on Mac OSX (10.5.x) that causes syslogd to hog the CPU. Plus a last resort solution to eradicate the bug.”

Hopefully that will lessen any confusion for future solution seekers. Thanks for bringing it to my attention.

How I wish that Apple would come up with a definitive fix either via a system update or by publishing a solution that all Mac users can find.
# 4 Chris Says:
August 22nd, 2008 at 1:54 am
Gianni:

“I got the message that the OS was running low on free space”

Now that ,is interesting — I have experienced similar messages — perhaps around the time when ’syslogd’ began to go haywire (I can’t be sure). In my case it was not iTunes though, my music and podcast collection is stored on an external drive, but nonetheless space on the system drive was running low.
# 5 Bookmarks about Cpu Says:
September 24th, 2008 at 9:00 am
[...] - bookmarked by 1 members originally found by gnarcotics on 2008-09-17 Mac OSX — Stop ’syslogd’ Being A CPU Hog http://blog24.co.uk/2008/07/23/mac-osx-stop-syslogd-being-a-cpu-hog/ - bookmarked by 3 members [...]
# 6 Gianni Says:
October 3rd, 2008 at 4:06 pm
Hello again!

I have spent some more time on this topic over the last few weeks, while still refusing to Archive and Install my OS. So, I just kept seeing the problem coming back until recently. Gradually I got closer to the true source, I am happy to report now. Combining new found keywords from various posts, for (re)searching again and again, it eventually brought me back to a surprisingly older thread and one post by forgie (see end of message).

Many people noticed correctly that while this runaway syslogd issue was happening on their Mac, apparently something invisible would gradually fill up all remaining free space on the hard disk. This is true, it being a system log file growing out of hand inside the hidden directory /var/log. Again syslogd is not to blame, it is only doing what an other process is telling it to do.

If left undetected the log can store millions of useless error messages until the file grows to gigabytes in size, A. this is not normal, B. it’s filling up all free space causing even more trouble. If you have somehow been able to kill syslogd successfully, this in some cases seems to thereafter cause the mdworker or mds process (spotlight indexer) to go haywire, for yet unclear reasons because it is not supposed to index any items inside /var/log stil it is related.

Inspection of the end of the affected log file will give you a clue to the application or process ID runing on your own Mac that is the culprit. There are for example reports of an old Mozy version conflicting with Leopard even after being uninstalled with the official installer. So again don’t blame Leopard, don’t blame the Syslogd, don’t blame the mdworker. Find your culprit and remove or update it.

In several cases people found many lines in the log like “OQT_MovieImport fseek_store: tried to seek to ; outside of file”. This clue is a nasty one, very misleading, because the culprit is in fact not the application reporting, but a deeper problem with a QuickTime component. Therefore people start searing in the wrong direction. Quicktime is being addressed (asked to perform a small or large task silently) by various applications, so it explains why there is such a great variety in problem reports.

Now, thank forgie for posting the missing link about removing old/outdates/expired 3ivx media components from his /Library/QuickTime/ on mactalk.com.au:
http://forums.mactalk.com.au/13/43557-itunes-7-6-syslogd-things-going-badly.html#post438724

The problem has not returned since I cleaned out those suspected QT media components much older than the purchase date of my MacBook and obviously not coming from Apple. I re-installed some of them after that, all is fine now QuickTime runs fine. A less drastic fix, it only took me a few minutes.

some other refs that helped to reach this conclusion:

http://emperor.tidbits.com/TidBITS/Talk/1687/

http://discussions.apple.com/thread.jspa?threadID=1517359&tstart=4

http://forums.macnn.com/90/mac-os-x/361819/great-crusade-against-10-5-mdworker/

http://www.spockboy.com/blog/archives/8

http://forums.macosxhints.com/archive/index.php/t-42338.html
# 7 Gianni Says:
October 3rd, 2008 at 5:12 pm
Ah, and i forgot to emphasize that this newest conclusion does confirm that not any individual file was corrupted like I had suggested in the earlier post.

It in my particular case it also once happened using the Finder when opening a folder containing a video file I just before exported from QuickTime Pro. The Finder in Leopard makes a preview icon using the Quicklook engine. In this case the processes com.apple.quicklook and com.apple.finder together spammed the system.log. The Finder Froze up but this didn’t mean that the video file was bad, as that would normally be my first thought.

Blog24

Social Media, Design & Blogging