0 com.apple.time 0x000000010f87a25c power_set_handler + 57
I think this is related to the fact that sometimes random windows will behave like something is leaning on the RET key. But this is not "dirty keyboard" behavior, because it is attached to a window. If I focus elsewhere, the new window doesn't get the repeating key, but if I go back to the first window, it resumes! Also it keeps happening when every USB device is disconnected from the iMac.
AntiRSI is also acting as if there is constant user input and never going idle, even after I've quit all apps: the timer never clears.
This seemed like the sort of way that Rowmote Helper might malfunction, but no, I killed that daemon and it's still going on.
Also keeps happening after I nuke /usr/libexec/UserEventAgent.
Any ideas?
See if the architect of your building is listed in Tobin's Spirit Guide.
I haven't had this exact problem (I know, I know) but have had several problems of the some-service-loses-its-mind on my Macbook, and the answer is always "delete the relevant com.apple.whatever.plist, repair permissions and reboot". HFS+ is a shit filesystem and something inside OSX is flipping bits it shouldn't. I suspect, but don't know, during installs/upgrades.
The relevant .plist(s) may be in more than one place, gotta catch 'em all.
Repair Permissions is best avoided, as explained by Gruber. It almost never fixes anything and often actually breaks stuff.
I will certain give that shill's advice from 2004 the consideration it merits.
Oh I'm sorry, if I'd realised you were just a troll I wouldn't have bothered replying.
My mistake.
Apology accepted!
Have you checked all your ports in case someone slipped you a Mouse Jiggler?
I regret that you are no longer on LJ for me to revise my earlier statement directly rather than add a second one. Clearly a Mouse Jiggler should not be pressing enter, nor should it be specific to an application.
I don't have a suggestion on how to fix it, but I can tell you what UserEventAgent (roughly) is. It's what the system uses as a medium between services and the system itself, and is a subprocess of launchd (of sorts). It handles a variety of plugins, such as Time Machine, AutoTimeZone, OpenDirectory, DiskUnmountMonitor, Airport, Bluetooth, Mouse, Location services, etc. If you want to find out what all it juggles on your system, check /System/Library/UserEventPlugins.
Sorry I can't be of more help.
Well, that all sounds like shit I don't care about at all, but since A) UserEventAgent was crashing at startup and B) now it's not running at all because I renamed the executable, it seems not to be the actual culprit here. Though "illegal instruction" does not seem like a thing that bodes well.
(I don't know what you mean by "Mouse" but my mouse appears to be working fine with no UserEventAgent running, so it's not critical to that.)
Turns out the culprit causing UserEventAgent to crash at startup was com.apple.time.plugin. I don't have a second 10.8 machine to check against; can someone running 10.8.2 tell me whether md5 /System/Library/UserEventPlugins/com.apple.time.plugin/Contents/MacOS/com.apple.time is c7bfcfd445b991f3e5e0b223f52cfc95?
Still unclear whether this has anything to do with the ghost-typing.
Is there some way to sniff input events and see where they're all being generated from?
$ uname -aDarwin minime.local 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
$ md5 /System/Library/UserEventPlugins/com.apple.time.plugin/Contents/MacOS/com.apple.time
MD5 (/System/Library/UserEventPlugins/com.apple.time.plugin/Contents/MacOS/com.apple.time) = c7bfcfd445b991f3e5e0b223f52cfc95
Yes, using Instruments, you can use the UI Recorder template (found in Mac OS X|Behavior) to capture all the mouse and key events going to a process.
I know this sounds like waving a rubber chicken, but try removing or re-ordering the RAM. Problems with bad RAM usually manifest as totally bizzare things like this. People think bad RAM will cause various bad things to happen at random times, but actually, it causes some unusual thing to happen pretty consistently.
This is also the source of HFS's poor reputation. HFS+ is rock solid, but it doesn't have any of the integrity checking that ZFS has. With so much of OS X using memory mapped files, plists get read into RAM, some bit gets flipped (bad RAM or just a cosmic ray), and things get written back to disk corrupted.
With disks and RAM storing so many bits these days, those 1 in a trillion odds that computer engineers never worry about are now happening all the time. I've got 240 trillion bits of storage in my office, and it's ridiculous to assume every single one is persistent.
HFS isn't actually a bad fs, it's just cosmic rays and ball lightning that are giving it a bad reputation on the Internet. Got it.
You believe stupid HFS+ IS SUCK memes from the internet. Got it.
I have never seen anything resembling a reasoned technical argument supporting the idea that HFS+ is as awful as people make it out to be. Does it have every feature in ZFS? No. Is it bad like FAT? Also no. Is its design obviously prone to data loss? Once again, no. Has it ever been noticeably better on some axis than the native filesystems of other operating systems? Actually, yes! Linux extN apparently didn't get tree structured directories or extent-based allocation until ext4 in late 2008. HFS+ had those 23 years before, in 1985, back when it was just plain HFS with no plus.
It's not perfect, but it's pretty far from "bad".
I think part of the problem with attitudes towards HFS is that as it's not very widely used, it's not very widely supported by cross platform tools. Even NTFS is pretty well supported on other OS's and FAT is used all over the place.
Basically, the technical merits of a files system does not correlate with it's internet popularity (except, perhaps, inversely).
That said, all of the above mentioned file systems do have one benefit not shared by RieserFS (see last column.)
Does this count? It seems fairly detailed and accessible, more so than anything else I've seen.
Yes and no. Some of the things he mentions are valid, some aren't. Especially silly things like criticizing HFS because it uses 16-bit values in some places, which basically screams "I am not a kernel programmer and I have no idea what things are like there".
But most importantly, what it doesn't do is demonstrate that HFS+ actually sucks, the way the lazy memes have it. Most of what Siracusa's going on about is his perpetual desire for enterprise-ish FS features to make their way to OS X. (Siracusa's massive OS X reviews are often as much about wishlisting as they are about reviewing.) Other features he mentions are traditional UNIX FS features which matter very little to the vast majority of Apple's customer base. E.g. do 99% of Apple's users care that, as a non-inode FS, HFS+ has to emulate hardlinks? Nope. They don't use hardlinks in the first place. Or sparse files.
Siracusa suffered a big letdown when Apple stopped work on their ZFS port due to legal issues created by Oracle's purchase of Sun. Ever since, he's been moping about it. The funny thing is, my guess is that Apple had no plans to actually replace HFS with ZFS. ZFS demands on CPU and RAM are a bit tough to justify for personal computers with a single disk, which is most of Apple's customer base. Also, ZFS was designed by geeks for sysadmins to use. It probably would not have been easy to sand down the rough edges for the general public.
p.s. JWZ, while I was reading the grandparent post in NetNewsWire, I hit space to scroll by a page and the key repeated for about 10 seconds. Without me holding it. So it seems you aren't the only one to have a 10.8.2 Mac haunted by keyboard ghosts.
It's contagious! I blame the CIA.
Well, I get my HFS+ suck from having to look after it since from before Macs suddenly became trendy with programmers, Unix geeks, and self-aggrandizing neckbeards. HFS was unreliable shit hat would break itself with tedious fucking regularity - and was considerably less reliable that FAT, in fact - and HFS+ was a MacOS 8 hack implemented for a co-operatively tasking OS that would shit its own bed often enough to keep Mac desktop support people in a job fixing corrupted filesystems. In the days when 16 MB was lots of memory.
I'm sorry you're butthurt about someone being mean about Apple's engineering.
Ungh, macs were basically a waste of everyone's time from after System 6 until OS X. So griping about HFS+ from the OS8 era isn't too relevant these days. The lack of sparse file support is still a bit annoying; but for most-day-to-day use it's been more than reliable enough. That said, as a geeky Unix sysadmin type, ZFS is fucking awesome; but requires tuning to get right & is definitely over the heads of Apple's target audience. It's a shame too, I have a friend who's business card while at Apple was ZFS Engineer.
But yeah, the CDDL was/is bad enough, but Oracle having bought Sun made everything in relation very questionable (see also: attempted threats over Google's Dalvik for Android), Apple did the right thing to ditch it unfortunately. By comparison, Disk Utility supports exFAT since Snow Leopard, because it has less dubious licensing, and go figure - that kind of stuff matters to businesses that make money in this sector. Apple has been treading very wisely in that regard in other ways, ditching gcc for llvm/clang being another example to wit.
But even then, the best thing ZFS offers is raidz3 (which unfortunately is a lifesaver on big RAIDs nowadays, hell, even Netapp/WAFLs RAID-DP was a lifesaver when it came out with DataOnTap 7, I had my bacon saved within a month of deploying a 2TB raw array shudder) & scrubbing. All the other things that would be great to have snapshots, deduplication, encryption, NFS, etc. are better done elsewhere or by other systems generally. HFS+'s one sore spot for some applications is lack of sparse file support, but Virtualbox et al seem to have figured how how to dynamically allocate their virtual disk images just fine even on HFS+ so this is basically a non issue.
I think the guy isn't butt hurt about Apple's engineering, but it sounds like you got burnt by OS8, which well... my god, there were real unixes, NeXT Step and many other choices in that era, I'm sorry you suffered needlessly.
If you want to look into decently licensed filesystems that offer some similar functionality to ZFS, DragonFlyBSD's HAMMER2FS looks the most promising. Oracle's sponsoring of btrfs and the recent hash attack, as well as its very rudimentary implementation at the moment, all make the linux world much saner when sticking with ext3/4 still.
I feel like I should include a flattr link to get some consulting time back for this post. ;)
Yeah, this. Rodger doesn't seem to make much distinction between the qualities of a FS design and the shortcomings of particular implementations.
Context matters too. All MacOS 8/9 filesystems lived inside an OS which permitted any buggy process to accidentally scribble on anything or hang the entire machine. Also, at that time HFS+ did not have journaling. Whenever things went boom (which was often), it was very easy for on-disk FS data structures to be left in an inconsistent state.
Well done, sir. Well done.
It's a good thing luxury-brand Apple went with the x86 vendor that refused to offer ECC support for "desktop" CPUs.
Sadly, it wouldn't matter if they'd gone with the other vendor. The only PowerMacs which supported ECC were the Xserve G5 and the very last G5 tower revision: a server and a workstation. Apple designed most PowerPC chipsets in house, so this was clearly by choice.