I ran into an interesting problem today. I don't think it's specific to the QRecall beta, but maybe there's something you can do with the beta that will help?

I was looking through my system log this afternoon, for something unrelated to QRecall. When I opened the log file in the Console app, what I discovered, alarmingly, was thousands upon thousands (by this time, it may well have been millions) of lines like this:

12/23/15 1:31:40.001 PM com.apple.xpc.launchd[1]: (com.qrecall.scheduler.agent[19322]) Could not find and/or execute program specified by service: 13: Permission denied: /Users/bgiles/Library/Application Support/QRecall/QRecallScheduler

12/23/15 1:31:40.001 PM com.apple.xpc.launchd[1]: (com.qrecall.scheduler.agent[19322]) Service setup event to handle failure and will not launch until it fires.

New lines were being added to the log file at a rate of just under 300 per second! I should note that QRecall wasn't the only program doing this. 1Password was doing exactly the same thing, at the same rate. The computer had been on for less than 4 hours when I discovered the problem, and already my /var/log folder was all the way up to system.log.786.gz.

Here's what happened, and how I fixed it.

A couple of weeks ago, I retired my 8-year-old 24" iMac, which originally had the QRecall beta on it. My home directory on the old iMac was called "bgiles". I also had a newer (only 3 years old) 27" iMac which I was repurposing to replace the old iMac. It also had a home directory called "bgiles", and it had also been running the QRecall beta. Both iMacs were running the latest El Capitan OS. I used Migration Assistant to transfer all the files from the old iMac to the new iMac. Migration Assistant will not merge two home folders, so it asked me to rename the account that I was moving from the old iMac. I chose the name "bgiles24". (James, you can probably already guess where this is going.) The transfer completed without problems, and now the newer 27" iMac had both a bgiles and a bgiles24 account, each with a separate home folder. My intent was to (eventually) clean out the "bgiles" account, transfer anything there that I wanted to keep to the "bgiles24" account, and then delete the "bgiles" account. I haven't had time to do that yet, so I had mostly been ignoring the "bgiles" account and logging in on the "bgiles24" account.

I should also note that I haven't hooked up the old external drive to the 27" iMac yet, because the external drive I had been using with the old iMac has a FireWire 400 interface, and the 27" iMac doesn't. So I hadn't actually run QRecall yet since doing the transfer from the old computer. If I had, maybe I would have noticed the problem sooner.

The problem, of course, was that QRecall was trying to talk to the scheduler, in a subfolder of "bgiles". Normally, this is no problem, but because Migration Assistant forced an account renaming, the folder that QRecall should now have been looking in would have been in the "bgiles24" path, not the "bgiles" path. QRecall had no way to know this, so it tried to look in the wrong folder, which it now had no permission to access. The result was error messages galore!

Once I realized what the problem was, I went to /Users/bgiles24/Library/Launch Agents and deleted the com.qrecall.scheduler.plist file. (It occurred to me later, that I could have just edited the file in BBEdit.) While I was there, I deleted a 1Password file in the same folder. I rebooted, and confirmed that the error messages were no longer being created, by either QRecall or 1Password. I then launched QRecall, and it created a new scheduler.plist file in the bgiles24 path that pointed to the copy of the scheduler that was also in the bgiles24 path. Problem solved. I then cleared out the hundreds of no-longer needed system.log files in /var/log.

Interestingly, 1Password hasn't recreated a file in the LaunchAgents folder, even after uninstalling it and reinstalling it, but it seems to be working fine nonetheless. As does QRecall, though I still can't do a backup until I get either an interface adapter, or a new drive.

So, everything appears to be back to normal, but is there anything you can do in QRecall to keep from generating so many error messages so quickly? Or is that the OS itself that was generating those? Had I not noticed the problem when I did, I can imagine that I would have run out of disk space fairly soon, and I hear that OS X gets really hard to work with when it runs out of disk space.

Bruce Giles wrote:So, everything appears to be back to normal, but is there anything you can do in QRecall to keep from generating so many error messages so quickly? Or is that the OS itself that was generating those?

This is 100% OS X. QRecall installs a number of "services" that are managed via launchd. Each service is defined by a configuration file (the .plist files in ~/Library/LaunchAgents for example). This is entirely set-and-forget; QRecall writes these configuration files and then expects launchd to manage the processes.

I'm actually surprised you had this behavior. In most circumstances, launchd will throttle a misbehaving service to keep it from chewing up all of the available resources. So if a service doesn't start, or starts but immediately terminates, launchd will ignore it for awhile before trying again. But 300 times a second is pretty much the opposite of "ignoring."

I'm going to file a bug report on this one, because it's clearly a simple misconfiguration that leads to serious problems.

For future reference, if you had just launched QRecall once it would/should have fixed the problem. When you launch the QRecall app, it tries to establish a connection with the scheduler (that launchd is supposed to keep running). If it can't, it then checks to see if the scheduler is properly installed. It should have discovered that the scheduler .plist file was misconfigured and rewrote it. That might not have immediately solved the problem (because launchd tends to cache the .plist info), but the next restart should have stopped it.

Had I not noticed the problem when I did, I can imagine that I would have run out of disk space fairly soon, and I hear that OS X gets really hard to work with when it runs out of disk space.

The word you're looking for is "nightmare." HTH