Getting errors related to "identity key", some "lost process" too

Note: I have six archives total : 3 archives on Disk 1 and 3 similar archives on Disk 2. I rotate Disk 1 and Disk 2 every week to an offsite storage area. This means that every week, a large number of actions are marked "waiting for archive" ... for instance while Disk 1 is offsite, every action for Disk 1 is marked "waiting for archive," and the next week same with Disk 2.

I do not know if this "offsite rotation scheme" is causing problems. So far most of the actions do complete, so as far as I know I have most of my data and layers intact.

But the numbert of errors over the past few days is enormous, so wanted to check.

Report sent.

Mike

Mike M wrote:Getting errors related to "identity key", some "lost process" too

The "identity key" and "lost process" errors are both bugs in macOS. We're hard at work on a new version of QRecall that should address these issues, but looking at your logs it appears that all actions (except the "identity key" ones) all ran and completed successfully.

If you have a question about the success of an action, the definitive resource is the log. If an action logs "<Some Action> complete" then that action ran successfully to completion. Each action runs as a separate process and the the only time it logs that message when it has started, accomplished its task without any major errors, and closed the archive. So if an actions logs "Capture complete", that capture was successful, no matter what else happened in the mean time.

The "identity key" errors are the result of a long standing, and rather annoying, bug in macOS. It has to do deadlocks that can occur when multiple tasks try to access the same preferences file. The Core Foundation framework is supposed to handle this, but starting around OS X 10.9 it sometimes gets stuck and never recovers. Some people have reported that sending a TERM signal to the cfprefsd daemon will sometime fix it, but a restart of your system will almost always resolve it. You encountered these on two days, and after restarting your system the next day the errors went away.

Note: I have six archives total : 3 archives on Disk 1 and 3 similar archives on Disk 2. I rotate Disk 1 and Disk 2 every week to an offsite storage area. This means that every week, a large number of actions are marked "waiting for archive" ... for instance while Disk 1 is offsite, every action for Disk 1 is marked "waiting for archive," and the next week same with Disk 2.

I do not know if this "offsite rotation scheme" is causing problems.

They aren't causing problems, but you'd probably be better off with a slightly different configuration of actions.

All of your actions have a "hold if no archive" condition. I assume this was left over from using the capture assistant to create them.

The "hold if no archive" is really intended for situations where you are capturing to a single external drive which is not always connected—a common case for external drives used with laptops. This condition starts the action but then places it on "hold" until the drive is mounted; it acts as a prompt that QRecall is waiting for the archive media and you should plug it in now.

Your situation is a little different. You have a set of actions that are expected not to run when their external drive isn't connected. I would suggest removing the "hold if no archive" condition and and replacing it with an "ignore if no archive" condition. This condition simply skips an action that targets an archive which is currently off-line.

Thanks, I did correct those "hold if no archive" to "ignore if no archive" . Should be cleaner now.