have you seen this error in system.log?

Yesterday it happened to me many times, I didn't check the system log at all but that was the behaviour.

In two circumstances this led to a system crash and I had also several problems in rebooting the machine. But since at that time I was playing with CoolBook and undervolting the CPU (plus adding also a 600Mhz entry for battery usage)... I thought that it was a consequence of my messing around.

Yeah, I get it on my MBP. It seems to usually happen after coming out of sleep mode. In my case, it always happens when Parallels is running before it went into sleep mode. There have been other cases talked about in the apple forums where people have seen this without parallels though.

It comes and goes on my Air (1.8 ssd, trouble-free so far) and I have seen it reported on Apple discussion forums. I only run the Mac OS and there are no third party apps short of a few popular widgets and Little Snitch 2.

I rarely reboot the machine. Right now the machine is up for 12 days and it is throwing that error tonight. A reboot does clear it away on my machine, at least for awhile. I just don't know what kicks it off again.

Maybe it's right that it's a sleep or wake from sleep issue. I had thought it was only the MacBook Air ssd machines that were doing this. I guess not if someone's macbook pro does it as well. That's the first I've heard of that.

1appleAday said:

hi all,

sometimes my Air cpu will almost max out for no apparent reason, so i open up activity monitor and see syslogd is running crazy (close to 100.00 under CPU). i then open system.log and see this error being written over and over again:

/usr/libexec/hidd[25]: IOHIDEventQueueEnqueue: Error enqueuing memory

sometimes it writes this error several thousand times!

since it's a new Air i brought it to the Genius bar. they ran some test but it all passed. then they contacted Apple engineers, who told them all Air is behaving like that and there's no fix as of now. feeling a bit skeptical i searched the system.log on one of the display machines, and i do see that in the log.

questions:

(1) can the Air owners out there search their system.log in Console? you can search for the error above. do you see many of them?

(2) the genius told me he doesn't know what syslogd does and not sure if it hurts if i kill it. obviously it's logging to system.log, but other than that does it do anything else? is it OK to kill it??

last remark: the genius says (well maybe the apple engineer, not remember exactly) this issue only happens for Air, but i googled it and found that some MBP also have the same issues. hmmm.....

thanks!

Click to expand...

syslogd is a core service... if you kill it, odds are you will experience instability at some point.

The issue here isn't really syslogd, but rather a daemon spamming the hell out of syslogd. Apple needs to fix that HID bug and the syslogd issue will go away.

Its a bug with the trackpad driver, it only ever occurs when your using the trackpad for input (it won't happen for example if your using a bluetooth mouse as your main input device instead) i raised it on apple bugreporting tool, but it was already raised, apple told me engineers were looking into it, i assume it will be fixed with 10.5.3.

Don't kill syslogd, instead killing the HID process will fix it (the HID process will automatically restart) that in turn causes syslogd to stop logging the error and maxing a cpu doing it, atleast until it happens again

I believe the MBP has inherited the problem due to it now also having the multi-touch trackpad, which is where the bug lies.

syslog cpu maxing possibly related to Little Snitch?

Hi, I just wanted to weigh in my opinion here. I've had the same problem of syslog using up 95-100% of one of the cores on my intel iMac (late 2006) running 10.5.2. So I don't think the problem is exclusive to the Air's. I've been scouring the net over the past few days for any potential clues but the problem seems to be rooted in a range of Apple and 3rd party apps. But I noticed that LizKat mentioned that they had Little Snitch 2 installed.

The only changes I had made to my system inbetween the syslog problem appearing (literally overnight) was to install Little Snitch. After creating a few rules allowing (and denying a single connection) I uninstalled it. However, after the uninstall and a reboot, the app whose outgoing connection I denied still was not able to access the internet. This led me to believe that Little Snitch does not fully uninstall itself and only after this did my syslog problem appear. I know that Little Snitch 2 is still in beta and also that it directly modifies the kernel and so led me to this conclusion.

On Krevnik's advice about not killing syslog due to possible instability: You can kill syslog without any problems although in my experience it will simply start up again later. I'm currently waiting on a reply from the dev team for Little Snitch but I wanted to ascertain whether anyone else was using Little Snitch so we could possibly narrow this problem down?

sandeepg said:

On Krevnik's advice about not killing syslog due to possible instability: You can kill syslog without any problems although in my experience it will simply start up again later. I'm currently waiting on a reply from the dev team for Little Snitch but I wanted to ascertain whether anyone else was using Little Snitch so we could possibly narrow this problem down?

Click to expand...

Yes, that's right, it would just start up again. You *could* comment out this line in /etc/syslog.conf:

*.notice;authpriv,remoteauth,ftp,install.none;kern.debug;mail.crit /var/log/system.log

then, when syslog restarted it wouldn't spam your log file. Of course, that would kill ALL your sysloging in the system.log. Not a good. idea.