Event Handlers

[cmgsupport]

Should the feature found in https://www.retrospect.com/en/blog/2017/06/06/script_hooks_in_retrospect be working with Retrospect 15 with OS X?  I have added and edited the sample .sh file, which should generate a log file and log every event, but it's not happening.  I can manually execute the .sh file and add some parameters to simulate an event and the log file is created appropriately, but the app itself doesn't succeed.  Should the script be owned by root instead of the user that put it in place?  The user was an admin of course.  How about an error log?  Would one exist? 

[PaulMikeC]

I have this issue too.

My Retrospect "backup server" is also my everyday workhorse computer, a Mac Pro (Mid 2012) tower running macOS 10.13.6 'High Sierra'. The  backups cover various local source volumes, including several internal, external & (occasionally) network drives, with the destination being a local 5-bay external enclosure, and are scheduled for overnight runs. I recently upgraded my Retrospect Mac Desktop Edition to 15.6.1 (from 13.5, and before that, 9.0, 8.x & 6.x), and was pleasantly surprised to see that this venerable Event Handling feature had been re-introduced in version 14.

Some more background info:- For extra insurance & convenience, I also use other services & utilities to make additional types of backups, such as Dropbox online sync, and emergency clone. For instance, I make a nightly bootable clone of just my tower's boot disk via Carbon Copy Cloner (CCC) v5.1. That work is split into two CCC tasks: the first one clones everything except my VirtualBox virtual machines (VMs)' storage files; and, the second one runs much later and clones only those VMs-storage files. That second task uses pre-flight and post-flight scripts to, respectively, pause and resume any running VBox VMs before and after the cloning. I would like to do the latter's equivalent in Retrospect, via event handling.

At the moment, I’ve simply copied as-is (from the 'Sample SH' subfolder in the Script Hooks download) the 'RetroEventHandler.sh' sample shell-script, into the boot disk's '/Library/Application Support/Retrospect/' folder. Unfortunately however, it seems I cannot get the Retrospect Engine to invoke the shell-script at all. I've tried various approaches, such as changing the file's ownership to 'root', restarting the Engine, and rebooting the tower, but all to no avail. (OTOH, for me too, the shell-script runs fine when manually executed in Terminal, either with appropriate test arguments or via the 'harness.sh' sample wrapper shell-script.)

Any assistance would be welcome.

[DavidHertzberg]

cmgsupport and PaulMikeC,

This Knowledge Base article says:

Quote

Retrospect triggers these events by calling a file named [my emphasis] "RetroEventHandler". This file can be any script type known to the operating system (As examples for Windows, BAT or VBScript. For Mac, bash or ruby).

My eventually-achieved understanding of the first sentence in that quoted passage is that you have to rename your script file to "RetroEventHandler" (without the quotes).  It is not sufficient to put the script file in the proper folder per the KB article.  Did you do the renaming?

Sorry it took me so long to spot that; I looked at the KB article several times.   I haven't messed with script files myself, but you could PM saskia.

P.S.: In view of what PaulMikeC has written directly below, my apology to him—and presumably to cmgsupport—for suggesting that he missed the KB article statement that the script must be named "RetroEventHandler" .  However I strongly recommend that he file a Support Case suggesting that either the KB article or the sample event-handler script(s)—or both—be revised to deal with the fact that the log file isn't generated in a directory where the script creator would expect to find it.  Here's why and how to do this.

Edited May 25, 2019 by DavidHertzberg
P.S.: Apology to PaulMikeC, along with suggestion that he file a Support Case

[PaulMikeC]

Hi David,

Yes, that thought had actually occured to me too, so during my experiments I did in fact also try removing the name-extension from the event-handler script file, and even in desperation changing the filename to all-lowercase, again to no avail.

However, I have in fact solved the issue, and it turned out to be a classic case of "User Error". 😉  Actually, the event-handler script does work fine when named 'RetroEventHandler.sh', and its owner can be left untouched (i.e., it does not have to be changed to 'root').

As a seasoned developer, I’m rather embarassed to have to admit that I was simply looking in the wrong place for the generated log file. I just plain forgot that since the event-handler script is being run as 'root' by the Retrospect Engine, a tilde ('~') character at the start of a pathname (such as the '~/Desktop/eventhandler_log.txt' file defined in the sample script's 'log' function) would of course resolve at run-time to the home directory of the 'root' user , rather than the logged-in user. So, when I looked instead in my boot disk's '/var/root/Desktop/' directory, there indeed was the expected log file, faithfully recording events all along!  {EDIT:- My 'root' account happened to have a Desktop folder, since long ago I used to enable the 'root' user (via Directory Utility) and occasionally log in as 'root' to perform some system tasks. On a typical system with the 'root' user disabled, there might be no such 'root' Desktop folder, and so the log file would not actually get created.}

For convenience, I’ve now changed the sample script so that the log file is written instead to the logged-in user's Desktop, by first obtaining that user's name via an idiom that I borrowed from a CCC sample pre-flight script, i.e. (in modern Bash syntax):

me="$(stat -f '%Su' /dev/console)"

and then inserting that 'me' variable's value to form the new log pathname: "/Users/$me/Desktop/eventhandler_log.txt".  {EDIT:- Although, it might be easier to just hard-code the log pathname, e.g.: if the same user is always logged-in on the backup server; or, to ensure the log gets written to a fixed location.}

Anyway, so sorry to have wasted everyone's time. At the moment, all is well with my tests of the sample event-handler script. Now to tackle implementing the VMs pause / resume functionality that I mentioned earlier.

--Paul

Edited May 25, 2019 by PaulMikeC
Added a couple of clarifications.

[PaulMikeC]

Hi again,

David, per your advice, I've submitted a Support Case requesting that at least the sample event-handler Bash script be adjusted to address this issue. I outlined a handful of possible approaches, ranging from merely adding a suitable comment to making various small code changes (including one based on my preceding post).

BTW, I've also managed to implement the VMs pause / resume functionality in Retrospect Event Handling that I originally wanted, by modifying the Bash script's 'StartScript' & 'EndScript' functions to detect my VMs Backup Script by name, and then respectively call my existing lower-level VBox VMs pause & resume shell-scripts (that are also being invoked by my similar "flighting" scripts in CCC). So, I'm fairly happy for now. 🙂

--Paul

[Nigel Smith]

On 5/25/2019 at 8:37 AM, PaulMikeC said:

For convenience, I’ve now changed the sample script so that the log file is written instead to the logged-in user's Desktop, by first obtaining that user's name via an idiom that I borrowed from a CCC sample pre-flight script, i.e. (in modern Bash syntax):

me="$(stat -f '%Su' /dev/console)"

 

Just a note -- that returns the username of the "current active GUI user" (for want of a better term). So if "backup" logs in it will give "backup", if "admin" then logs in using multiuser switching (i.e. "backup" is still logged in but "admin" is active) it returns "admin" -- and if "admin" logs out (but "backup" is still logged in) it returns "root" because you are at the login window. May not be an issue for you with your setup but it would confuse the hell out of me...

I tend to hardcode these things -- apparently /var/log is a popular choice for log files 🙂

On 5/25/2019 at 8:37 AM, PaulMikeC said:

Anyway, so sorry to have wasted everyone's time.

I'm glad you did! I've never got Script Hooks to work and had assumed the system was borked. Now you've shown otherwise I'll attack it again. Slack integration, here we come!

[PaulMikeC]

Hi Nigel,

That '/dev/console' idiom seemed to come closest to what the tilde ('~') char in the original sample script was meant to do. As you pointed out though, it could end up varying too much, depending on login patterns. That's why, in the second parenthetical '{EDIT:- …}' in my post of 25th May, I too had suggested that it might be easier to simply hard-code the log pathname. {In fact, I myself later switched to doing just that, so my log file is always on the main user's Desktop. I'm now thinking about incorporating some kind of automatic log rotation (perhaps similar to what the OS does for system logs) with zipping, etc.}

I do also hope that you got your Slack integration to work! 🙂

—Paul