I've been having intermittent problems with Qrecall on my MacBook Pro for a couple of weeks. A backup might run all the way through, then report a problem closing the archive when it was done. Sometime immediately rerunning the backup immediately seemed to fix the problem. Yesterday and today, though, Qrecall is consistently freezing as soon as I try to open an archive, requiring a force-quit to get the computer back. This happens with three different archives on two different hard drives. Repairing the archive appeared to fix a number of problem in the archive but not solve the freezing issue.

My next step, I think, should be to reinstall Qrecall from scratch, and I'm wondering what Qrecall files I should trash I should discard as part of my cleaning process before I do that.

Ralph

To answer your question, QRecall can be uninstalled casually by holding down the Option and Shift keys and choosing QRecall > Quit and Uninstall command. For a thorough uninstall, see Help > QRecall Help > Guide > Advanced > Uninstall > Uninstall (the hard way).

However, I don't think uninstalling QRecall is going to fix anything.

Looking at the diagnostic report you sent, the QRecall app is hanging when it tries to open the archive file(s). Specifically, the call to open the file hangs deep in the filesystem. You can see this in the .hang file where QRecall calls open(), which eventually get stuck in check_file_access() > lck_mtx_sleep_deadline() > thread_block_reason().

Also, several actions are getting stuck obtaining write access to the archive files. Finally, one action crashed trying to close a mapped file in the archive.

All of these symptoms point to a problem with the drive or server that contains the archive. If it's a server or NAS, I'd first suggest restarting it; the server might have stale file semaphores that are causing problems. It might be connectivity problem. It also might indicate hard drive issues. It's hard to tease out a culprit from the logs, but that's the direction I'd look in.

I've uninstalled and reinstalled Qrecall, and as you predicted, that didn't make any difference. I have a better handle now on the problem, though, and I think the underlying cause is the High Sierra update.

I backup an iMac and a MBP to the same archive, and swap between two archives, one of which is stored offsite. The active archive is routinely mounted on the iMac, but gets mounted briefly on the MBP for maintenance when I make the swap. The difficulties I'm having all seem to come from my MBP, which I upgraded to 10.13.2 a couple of weeks ago. (The imac is still on 10.12, and will stay that way for a while.)

The freezing that I described when opening an archive turned out to be only a temporary hang. I just wasn't waiting long enough for it to resolve. Backups run on the MBP are still causing errors that require repair of the archive, and I've had to repair both archives.

Once Qrecall opens an archive, the only way to unmount that drive (without just pulling the plug) is to shut down the computer. Eject won't work, it just produces a notice that something else is using the file. This persists even when Qrecall and all other running apps have been quit, and even when I've logged out of my account and try to eject the drive from a different account. The only way to disconnect the drive seems to be Shutdown. The problem does not occur with files opened by other apps.

I'm sending a report, but I don't need you to spend any more time on this right now. Qrecall is working fine on the iMac, so I can keep it backed up from there. I'll stop using Qrecall for the MBP until macOS 10.13.3 comes out, and see if that fixes the problem.

Thanks again for the great support you provide.

Ralph

Ralph Strauch wrote:Once Qrecall opens an archive, the only way to unmount that drive (without just pulling the plug) is to shut down the computer. Eject won't work, it just produces a notice that something else is using the file. This persists even when Qrecall and all other running apps have been quit, and even when I've logged out of my account and try to eject the drive from a different account. The only way to disconnect the drive seems to be Shutdown. The problem does not occur with files opened by other apps.

If you believe the problem preventing your volume from unmounting is an open file or files, there's an obscure command line tool that might help track the culprit.

The lsof (list open files) tool will list all of then open file descriptors in your system. Use the +D option to filter the list to only those items contained within a specific directory/volume, like this:

sudo lsof +D /Volumes/Stuck

will list the files/directories that are open on the volume Stuck. More importantly, the list includes the name of the process that opened the file and the user account it's running under.

I'm still unable to back up my MBP running High Sierra. I thought I had posted a recent summary yesterday, but don't see it here so perhaps I forgot to hit send. I did submit a report yesterday.

Since my problems looked like they might have been drive or network issues, I ran a new backup of my MBP on a clean drive (7th bu.quanta in the log). The first time I ran it (2017-12-31 21:58:14 it failed, but I was able to repair it. I reran it and seemed to go to completion(2018-01-02 16:37:01) but the log showed communications problems, so I Verified the archive (2018-01-03 07:36:11) and the verify log listed communications problems. The drive I used for this backup was a firewire 800 drive connected through a TB to FW adapter, while my regular backup drives are USB3.

One issue I'm having consistently through this is that Qrecall tends to hang up and ask for a Force Quit. It will sometimes unhang itself after several minutes if I leave it alone.

Ralph,

Here's what I found going through your logs.

First, I apologize for the "lost communications" errors you're getting. These are random interprocess communications failures caused by the legacy Mach Ports service. The only way to fix this is to completely rewrite QRecall to use the modern XPC communications. This work has already been done, but won't appear in QRecall until the next major version.

QRecall seems to be working as expected, although I can see why you might think there are problems.

The first set of actions are exactly as you described. You created a new archive (7th bu), started a capture, stopped it, started it again and let it finish.

Except for two issues, this all ran flawlessly. The first issue is that at some point (probably when uninstalling and reinstalling) QRecall is no longer pre-authorized. All of the capture actions are running with user-only privileges. This resulted in vast swaths of system files not being captured and reporting "Could not capture file/Insufficient privileges to read file/Permission denied" errors. It also explains the "Capture encountered problems" warning you see at the end.

The second issue is, of course, the lost communications link between the helper process performing the capture the the monitor app displaying its progress. My suggestion, for QRecall 2.0 and any macOS after 10.10, is to take any loss of communications error with some healthy skepticism. Instead of assuming the process has crashed (the original intent of that error), check Activity Monitor and see if the QRecallHelper process is still running. If it is, ignore the error and check back later to see what the log says. If the process completed successfully, it will log some king of completion message (hopefully "Capture finished"). That's the definitive answer to whether the action was a success or a failure.

2018-01-01 12:18:24.558 -0800 Capture finished (14:19:55)

You then restarted your computer and repaired the archive. Because there was nothing wrong with the archive, the repair completed successfully and reported no issues:

2018-01-02 14:43:12.323 -0800 Repair finished (2:31:33)

You then ran another capture followed by another verify:

2018-01-02 16:37:01.695 -0800 Capture finished (38:32)

2018-01-03 10:17:55.594 -0800 Verify finished (2:33:33)

Again, except for not having permissions to capture any system files and some communication failures, both actions ran successfully and to completion.

At this point I would suggest you re-pre-authorize QRecall to use administrative privileges. Go to QRecall > Preferences&hellips; > Authorization and turn on "Capture and recall items using administrative privileges". Then recapture your hard drive (this will take a bit since there is now a whole bunch of new stuff to capture).

Finally, I don't know what's causing the QRecall app to freeze on you. I don't see any '.hang' reports auto-collected by the system. If it happens again, launch Activity Monitor, select the QRecall app (which should say "not responding"), choose View > Sample Process (Option+Command+S), and send me the resulting report.

Thanks for the reply, James. I guess I've been thinking qrecall had problems at times when it didn't, and knowing that I can ignore some of the "communications problems" gives me more confidence. I just ran an MBP backup on fresh drive and it went without a hitch.

All is not yet well, though. I ran another backup of the same system on one of my older archives, and it stopped running after about 2 hours and the computer gave me a "Drive not Ejected Properly" error message. When I looked at the Finder, however, the drive was still plugged in and connected. The qrecall activity window stopped at the point where this happened, showing a partially completed backup. So somehow qrecall lost contact with the drive but the computer didn't. The Qrecall log stops with "Capture Issues." Activity Monitor show Qrecall, Monitor, Scheduler, and two versions of Helper still running.

I just walked into the other room where my iMac was running a repair on another older archive to find the same situation. Qrecall said that the drive was not ejected properly, but Finder still finds it there. The last entry in the Qrecall log is Repair, twice. Activity monitor shows Qrecall and two versions each of Monitor and Scheduler, no Helper.

Lastly, as I'm writing this, the MBP just popped up another "Drive not Ejected Properly" message, while the drive is still sitting there, connected but not being accessed afaik.

Both of these drives are 3-4 years old, and perhaps they've outlived their usefulness. In general, though, they seem to work. Can you tell anything more about what's happening from my logs?

Ralph



Ralph

Ralph Strauch wrote:Lastly, as I'm writing this, the MBP just popped up another "Drive not Ejected Properly" message, while the drive is still sitting there, connected but not being accessed afaik.

I suspect this is happening more that you realize. The pattern I typically see is an intermittent hardware problem (external bus, cabling, power supply, drive controller, and sometime software) that causes a drive to spontaneously disconnect. It will then, almost immediately, reconnect so by the time you turn around it's already reappeared on the desktop.

This can occur repeatedly, without notice or harm. But when it occurs during a long-running process (like a QRecall capture or repair), then it can cause problems.

I looked at your logs. The QRecallScheduler process monitor and logs mount events. So I can tell that on your iMac, for example, your external volume BUD3 has unmounted and then immediately remounted itself over 60 times in the past month. Here are some recent examples:

2017-12-30 13:32:20.434 -0800 unmounted volume /Volumes/BUD3
2017-12-30 13:32:50.260 -0800 mounted volume /Volumes/BUD3

2017-12-30 13:32:50.983 -0800 unmounted volume /Volumes/BUD3
2017-12-30 13:32:54.054 -0800 mounted volume /Volumes/BUD3

2017-12-30 21:13:12.937 -0800 unmounted volume /Volumes/BUD3
2017-12-30 21:13:42.762 -0800 mounted volume /Volumes/BUD3
2017-12-30 21:13:43.982 -0800 unmounted volume /Volumes/BUD3
2017-12-30 21:13:47.059 -0800 mounted volume /Volumes/BUD3

2017-12-30 21:15:31.133 -0800 unmounted volume /Volumes/BUD3
2017-12-30 21:16:00.896 -0800 mounted volume /Volumes/BUD3
2017-12-30 21:16:02.297 -0800 unmounted volume /Volumes/BUD3
2017-12-30 21:16:05.435 -0800 mounted volume /Volumes/BUD3

2018-01-02 15:25:25.290 -0800 unmounted volume /Volumes/BUD3
2018-01-02 15:25:54.687 -0800 mounted volume /Volumes/BUD3
2018-01-02 15:25:55.759 -0800 unmounted volume /Volumes/BUD3
2018-01-02 15:25:58.805 -0800 mounted volume /Volumes/BUD3

2018-01-06 08:49:29.136 -0800 unmounted volume /Volumes/BUD3
2018-01-06 08:49:58.800 -0800 mounted volume /Volumes/BUD3
2018-01-06 08:50:00.213 -0800 unmounted volume /Volumes/BUD3
2018-01-06 08:50:03.285 -0800 mounted volume /Volumes/BUD3

2018-01-06 12:23:50.293 -0800 unmounted volume /Volumes/BUD3
2018-01-06 12:24:19.997 -0800 mounted volume /Volumes/BUD3
2018-01-06 12:24:21.318 -0800 unmounted volume /Volumes/BUD3
2018-01-06 12:24:24.404 -0800 mounted volume /Volumes/BUD3

As you can see, the volume occasionally unmounts, and then a few seconds later is mounted again. In most cases it does this again within a few seconds.

Honestly, the cause of this kind of thing can be difficult to track down, but swapping out components (try a different cable, swap power supplies, switch from eSATA to USB or vice versa) might narrow it down.

What seems to be happening is that both of my USB drives are spontaneously unmounting and remounting, and when my FW drives is mounted along with a USB drive, it unmounts and mounts at the same time. If the FW drive is mounted by itself, though, it's solid and doesn't unmount. Thanks for pointing out the logs to me; I can use that to troubleshoot the cables and power supplies.

I've been having a problem, though, trying to open ~Library/Logs/Qrecall/Qrecall.log in Console, because when I click on it, Console freezes up. The older logs open fine; just the current log freezes. When I looked at that log in Finder, I found the problem. it's 14.32GB. Yes, GB, and that's just since the first of the year. No wonder Console was choking on it. When I open the file with Quicklook, it looks like most of it was written yesterday. Can I just pull that file out of the Logs folder and start a new one? DDo you have any sense of what's going on here, and do you want this monster for anything?

Ralph

You/I/we probably don't need that log file, as you seem to have a handle on the issue.

Feel free to toss your QRecall.log file(s) and restart; a new will be automatically created.