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.

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

“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.

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.

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’.

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.