Hi,

I was undescribable delighted when I read this new feature in the 2.1 release notes:

If you attempt to log out, shutdown, or restart while (monitored) actions are running, the activity monitor will let you stop the actions, reschedule them to run later, or hold the shutdown until they finish.

I am backing up to an archive on a NAS, and regularly when shutting down my Mac or putting it to sleep while an archive operation is still in progress, the archive usually becomes corrupt and I need to repair it (taking about a whole day) before I can work with it again after the next boot. That option, I figured, would prevent this from happening in the future.

Alas, shortly after I installed the new version and inadvertently restarted my Mac some time later, a backup operation was still in progress. What then happened was that from the monitor window, a sheet opened that should let me make my choice before the restart/shutdown continued. However, at that time, (a) my mouse was inoperable, (b) as was my keyboard, so I couldn?t operate that dialog sheet, and Mac OS continued its shutdown procedure, closing all apps, blanking the desktop to black (with the sheet still showing from the monitor window, but inoperable), and (c) finally the Mac shutting down completely, taking the QRecall monitor window with it. Result of course was that the archive needed repairing afterwards.

I am running on Mac OS 10.11.6.

Are there any specific circumstances where the prevention of shutdown would not work? Does the Advanced preference ?Actions Run as a Background Process? have any influence on this feature? I think I had it set to ?false? already at that time.

Maybe best thing for me is to create a tiny test archive (where repairing is cheap) and try a shutdown again. James, in case what I described is not the way it should work, is there any special debugging I should turn on before further testing? Any specific Advanced Preference values to set? Any specific procedure to try to generate best possible logging info? I?ll gladly test and investigate this further, as it is such a welcome and vital feature for me: preventing archive corruption due to accidental Mac shutdown/sleep.

Thanks for any guidance,
Christian

Christian,

You'll appreciate that we were indescribably disappointed when this feature stopped working.

Yes, we added a dialog sheet to the QRecall Monitor user agent which presents a dialog asking you what to do about the actions that are running before shutting down. A GUI app that presents a dialog in response to a shutdown-releated quit request will halt the shutdown.

This was all working great during the beta period.

Then, suddenly, it stopped working so well. I'm not sure if it was the result of an OS upgrade or was just dumb luck, but now the QRecall Monitor may, or may not, halt shutdown. On many of my test systems I can actually see the dialog sheet roll out, only to watch macOS immediately terminate the app anyway.

*sigh*

I've reported this to Apple and I'm looking for a workaround, but for now this features is only semi-functional.

Thanks so much for the info. I knew this function was too good to be true

Well, my accidentyl ?shutdown while still backing up? often happened because the monitor window (though set to show on all spaces) was obscured by other open windows. Now I just noticed (don?t know how long this is there already) that the ?Q? menubar item title receives a grey center dot when an activity is in progress. Since the menu bar is visible all the time, unless I forget to peek there, that should help stop me from accidentally shutting down my machine in that case.

A final question: Does a QRecall activity in progress get a chance by the OS to clean itself up before it gets killed by the shutdown process? Asking if it was possible to cleanly stop any activity in time (and closing the open archive correctly) before shutdown actually happens. I seem to remember you actually implemented it that way, but that either there?s a hard time limit (10 seconds? - which with a >1TB archive I will always miss) or the SMB protocol network underpinnings go away earlier, so the process cannot finish writing to the NAS). But I?m not sure about the details on this one.

As for my original question, I?ll simply try to forget this function ever was intended to exist. Being on 10.11.x with no further upgrade path (Mac Pro 2009), I won?t receive any OS fix (if that is what it needs) anyway.

Thanks
Christian

Christian Roth wrote:A final question: Does a QRecall activity in progress get a chance by the OS to clean itself up before it gets killed by the shutdown process? Asking if it was possible to cleanly stop any activity in time (and closing the open archive correctly) before shutdown actually happens. I seem to remember you actually implemented it that way, but that either there?s a hard time limit (10 seconds? - which with a >1TB archive I will always miss) or the SMB protocol network underpinnings go away earlier, so the process cannot finish writing to the NAS). But I?m not sure about the details on this one.

When shutting down, macOS first sends a TERM signal to each running process. A QRecall action interprets a TERM signal exactly the way is does the "stop" button in the monitor; it attempts to immediately cancel what it is doing and cleanly close the archive.

However, the shutdown usually only give it about 30 to 60 seconds to wrap up. If you have a big archive on a networked volume, that probably isn't enough time. If the process is still running, macOS will then send the process a KILL (force quit) signal, which usually leaves the archive in an unfinished state.

Most actions, however, should tolerate this. The common actions (capture, verify, merge) can be randomly killed and the next action will auto-repair the archive and continue on as if nothing had happened. The problematic actions are compact and repair, which cannot tolerate being KILLed, requiring the archive to be repaired.