Most of the issues I reported earlier have been fixed as stated in the release notes. Thank you!

One problem remains: I still can't restart QR scheduler after forcing it to quit in the Activity Monitor. Quit and restarted QR several times, but the scheduler never came up. A diagnostic report has been sent.

The issue isn't mentioned in the release notes, I know. Just thought it might have been solved with all the changes made to the scheduler.

Other issues:

1. I used "sudo qrecall captureprefs list -r -s /" to check the QR Capture Preferences settings, and it aborted with the following error midway through the process:

* failed to read directory

This, in fact, isn't new. I ran into this as well with b10, but forgot to report it. Sorry.

2. There are a few dozen of "Unable to communicate with helper" warnings and one "Unexpected problem; scheduler stopping immediately" error in the log. The error happened more than 6 hours ago, so no report was sent. I'll send a report should I spot it sooner next time.

Ming-Li Wang wrote:One problem remains: I still can't restart QR scheduler after forcing it to quit in the Activity Monitor. Quit and restarted QR several times, but the scheduler never came up. A diagnostic report has been sent.

I'll look into this.

QRecall's scheduler is managed by the launchd service. launchd is set to run the scheduler all the time, unless the QRecallScheduler process exits with a non-zero status. launchd will also throttle, or eventually stop running, the scheduler if it repeatedly crashes or is forcibly terminated too often.

If you're force quitting (SIGKILL) the scheduler, I would expect it to restart. If you're soft quitting (SIGTERM), the scheduler should immediately clean up and quit with a status of 0; launchd should immediately restart it. If you interrupt (SIGINT) the scheduler, it will deliberately exit with a non-zero status so that launchd does NOT restart it. It will also exit with a non-zero status under certain circumstances, such as with some internal errors.

Relaunching the QRecall application won't help, because it's launchd's run the process. If launchd has decided not to run the scheduler, you'll need to log out and back in (if "Run actions while logged out" is turned off), or restart the system (if "Run action while logged out" is turned on), to get it going again.

Anyway, diagnostic reports will help. They should tell me if the scheduler is terminating early, terminating with a non-zero status, or repeatedly crashing.

Other issues:

1. I used "sudo qrecall captureprefs list -r -s /" to check the QR Capture Preferences settings, and it aborted with the following error midway through the process:

* failed to read directory

This isn't surprising, because you don't have permission to read those directories. Use sudo qrecall captureprefs list -r -s / instead.

I'll put an item on the wish list for qrecall captureprefs -r to continue if it can't read the contents of a directory.

2. There are a few dozen of "Unable to communicate with helper" warnings and one "Unexpected problem; scheduler stopping immediately" error in the log.

Hmmm. The "scheduler stopping immediately" error might be the reason your scheduler isn't running...

James Bucanek wrote:QRecall's scheduler is managed by the launchd service. launchd is set to run the scheduler all the time, unless the QRecallScheduler process exits with a non-zero status. launchd will also throttle, or eventually stop running, the scheduler if it repeatedly crashes or is forcibly terminated too often.

At the time of my posting, there was one "Unexpected problem; scheduler stopping immediately" error in the log, and I force quit it once (in Activity Monitor). They are hours apart. I doubt that qualifies as "too often".

Relaunching the QRecall application won't help, because it's launchd's run the process.

Is it possible to have a "Restart Scheduler" command on QR's menu, perhaps next to the "Restart Monitor" command (which, btw, is almost never used since the Monitor always restarts itself very quickly)?

Ming-Li Wang wrote:1. I used "sudo qrecall captureprefs list -r -s /" to check the QR Capture Preferences settings, and it aborted with the following error midway through the process:

* failed to read directory

This isn't surprising, because you don't have permission to read those directories. Use sudo qrecall captureprefs list -r -s / instead.

I did use "sudo", didn't I?

Hmmm. The "scheduler stopping immediately" error might be the reason your scheduler isn't running...

I doubt it. As said, the scheduler went away and never came back only after I force quit it. The error in the log happened several hours earlier without my immediate knowledge. The scheduler apparently restarted itself without issue; otherwise I would have nothing to force quit.

Ming-Li Wang wrote:I did use "sudo", didn't I?

Yes, you did. I don't know how I missed that...

I couldn't reproduce this on my development system, but I did see it on a test MacMini, so I'll investigate this further.

Thanks for sending the diagnostic reports with the scheduler failure. And to answer your question, no the QRecall application can no longer force the scheduler process to start/stop. Recent changes to the launchd and launchctl tools make process management the sole responsibility of launchd.

It's a moot point, since adding a feature to manually start the scheduler process is more hack than solution. If you want to do that, just start it from the command line:

QRecallScheduler &

Good. I like command line. Thanks!

After spending some quality time with your log, I found a couple of instances where the scheduler stopped due to uncaught exceptions, mostly to do with spurious mount notifications for the recovery partition. (Under normal circumstances, the recovery volume should never be mounted, so it's a mystery why the scheduler would be receiving these...)

I've plugged those leaks, but even those wouldn't have caused the scheduler to exit with a non-zero status. So why launchd isn't restarting it remains a mystery.

I even specifically found instances where you had force-quit the scheduler, and launchd didn't restart it.

But see my reply to the slow-down issue you reported for a possible clue.

On a side note, it's best to try quitting (SIGTERM) the scheduler first before resorting to a "force quit" (SIGKILL). A quit gives the scheduler a chance to save the information it has about running actions before terminating. This helps it restart smoothly.