Automated Script Not Launching

[nazteq]

Using Retrospect Desktop v6.1.126 on an Intel Mac w/10.4.7 to backup my Home directory every night at 10pm. Worked for about 5 months, now the script won't automatically launch.

 

If I launch Retrospect in the morning after it failed to launch at 10pm the night before, the script will automatically engage, run and then Quit, closing the app. Seems the script will run at 10pm after that until some threshold is crossed liking restarting, not sure yet.

 

I noticed this was a known problem under v6.0 on Tiger but supposedly fixed under v6.1.

 

Is the failure to launch an automated script a known problem again under certain configurations?

[rhwalker]

Yea, it happens to us every few months. Here's the fix for us (from natew):

(1) quit Retrospect.

 

(2) Kill the RetroRun process:

From terminal:

ps axl | fgrep Retro

identify the RetroRun process, then, replacing "retropid" with that process ID:

kill -1 retropid

 

(3) manually delete /Library/Preferences/Retrospect/retrorunfile

 

(4) manually delete /Library/Preferences/Retrospect/LaunchRetroHelper

 

(5) manually delete the folder: /Library/StartupItems/RetroRun

 

(6) reboot the machine, launch Retrospect once, then quit. This regenerates the files & folders deleted above.

 

This is the same sequence to fix the "two instances of Retrospect running" problem.

[CallMeDave]

More steps then necessary.

 

All that's needed is (3) and half of (6).

 

retrorunfile is a datafile that gets corrupted or populated with incomplete data. Since retrorun looks to retrorunfile for when to launch Retrospect, incorrect data will lead to a failure to launch.

 

Retrospect writes updated data to retrorunfile every time the program quits. It needs to quit cleanly for this to work (a feature that could use some redundancy). A new instance of retrorun (with a new PID) is spawned each time Retrospect is launched. So step 6 refreshes the unix daemon without any need to delete the startup file (which doesn't get corrupted in any way).

 

There's no need to reboot to solve the problem with scripts failing to auto-launch.

 

As for "This is the same sequence to fix the "two instances of Retrospect running" problem," that's the first time I've heard that claim on the Forum. If there's an existing thread where this was fleshed out, I'd love a link.

 

Dave

[rhwalker]

Quote:

---

More steps then necessary.

 

All that's needed is (3) and half of (6).

 

---

Thanks, Dave, for the simplification. You know more about Retrospect internals than I do.

 

Here's where the above came from:

Re: 2 instances running at the same time & error -45 file locked

 

I have only seen the "two instances of Retrospect" once, but I keep this little incantation around.

 

Regards,

 

Russ

[nazteq]

Just deleted the file, launched Retrospect, noticed new file generated.

 

Will see if it kicks off on Monday night....

[nazteq]

Monday night kicked off just fine.

 

Thanks for the help!

[rhwalker]

Nazteq,

 

Simply FYI, Walter Reed of EMC/Dantz wrote a cron script to act as a safety net, and launch Retrospect if it hadn't launched on schedule. You can search for it in the Knowledge Base or Retrospect support utilities. We don't use it because this is such a rare occurrence (every few months) and also because there are times when you don't want Retrospect to launch (because you have turned off the schedule), as might happen when you are in deep repairing an OS crash or doing a software update, etc.

 

I don't know about you, but whenever I have seen it, and start Retrospect manually to check out why it didn't launch, it will realize that it should have started and will start backing up, but that delayed backup seems to happen with the wrong UID (not setuid root), such that privileged files on the server give errors. The fix I described above makes all right with the world.

 

As Dave mentions, it would be nice if the Retrospect programmers could track this rare problem down.

 

Regards, and glad your problem is solved.

 

Russ

[nazteq]

Just happened again. Bottom line to me - I depend on the timer to save my data, I don't want to have to stumble across the problem when I happen to open the app to view the log after it hasn't worked for weeks. Seems like a major problem that should be solved.

[rhwalker]

Quote:

---

Just happened again. Bottom line to me - I depend on the timer to save my data, I don't want to have to stumble across the problem when I happen to open the app to view the log after it hasn't worked for weeks. Seems like a major problem that should be solved.

 

---

If you've got email notification set up, you will get an email each morning with completion results. When the emails stop coming, you know that it's not launching. That's how I notice.

 

I agree with you that this problem needs to be fixed. It has gone on for a long time.

 

Russ

[elurie]

This has been happening to me since version 4. I believe. Once launched, it often starts launching automatically for a while.

It also happened to me with clients running Retrospect Express on several versions.

 

This is the first time i have been able to find anything about it on the forum. I am grateful for this info. and for the tip on setting up email notification. I had forgotten that was an option and never figured out how to set it up.

--------------------------------------------------------

mac os 10.4.7, retrospect v.6.1.126, rdu rdu619102

eve

[nazteq]

Associated Issue? - If Retrospect has failed to launch for some time, you restart the computer and before you can login Retrospect launches in the background with request for root access?

 

Truly annoying.

[nazteq]

Tried to follow the steps to engage emailing (modify a script?!) and got stuck on Step 1 - Point Retrospect Event Handler to the location of your mail app. Manual doesn't spell out how to point it and when I double-click my only option is to edit.

 

I added my email address but doesn't work, probably because the script doesn't know where the app is? Also, after restarting the computer, my screen goes blank during startup and the script is no longer editable; the REH app launches then closes down.

[rhwalker]

The only Retrospect Event Handler / email notification that really works is the Python version. Reason being, it isolates you from changes in the mail client interface, and does the emailing via Python.

 

Python event handler

 

Setup is really rather straightforward; no change is needed to the macmail.py file. If you have difficulty, send me a private message with your email address and I will be glad to try to help you get it going, and there's a minor bugfix that was posted in the forums about a year ago to allow email addresses of the form

"User Name" <user@domain.com>. It's a bit difficult to have that discussion via the forums.

 

Russ

[nazteq]

I finally got Python rolling, still have retrorun file corruption. I noticed that now that Python is in my Prefs, the first time I launch Retrospect it immediately closes and I have to launch it again. Another known issue with another fix?

[nazteq]

Spoke too soon. I deleted the retrorunfile and restarted and then launching worked properly; deleting it without restarting did not. However, now email isn't working again. What a mess. Hoping v7 is better...

[nazteq]

Is the corruption of the retrorunfile an incompatibility with Intel?

 

I now have a client that is having the same problem. He cannot rely on Retrospect and has asked me to provide an alternative. I tried to work with Retrospect via email, their solution was to uninstall/reinstall; not willing to go thru the pain and suffering unless I have some hard evidence it will help and for more than a little while.

[rhwalker]

Quote:

---

Is the corruption of the retrorunfile an incompatibility with Intel?

 

---

No. It's been an issue for years, and is a general Retrospect bug that happens on PPC as well. We see it every month or two on our Xserve G5.

 

As I see it, there are three solutions (well, one solution and two workarounds):

 

(1) perhaps someday the Retrospect programmers will fix this long-standing bug. That's the only solution, but doubtful because we've been experiencing it for years without any progress on this front. I've sent corrupt retrorunfiles to Retrospect support under our support/maintenance contract, don't know if anyone has ever taken the time to look at them. But it's somewhat easy to reproduce - just give me a month....

 

(2) a cron job each night, AFTER backup, to manually delete /Library/Preferences/Retrospect/retrorunfile , then launch Retrospect and quit Retrospect (can be done by Apple Events). The retrorunfile is re-written on each quit by Retrospect. Unknown what causes it to become corrupted, but this would be a workaround.

 

(3) Use the cron script written by Walter Reed, formerly of EMC/Dantz/Retrospect tech support, to provide its own launch mechanism for Retrospect. That script is available in the Retrospect Knowledgebase:

TS_Scheduler script

Note that it creates a log file that grows unbounded, and that you will have to delete periodically.

 

There's a difficulty that we have in using this cron script by Walter Reed, completely unrelated to all of this. Before making any software changes to our Xserve's OS volume, we clone that disk using a RAID 1 mirror split with Retrospect's schedule turned off (so that Retrospect doesn't autolaunch with pending scripts during the middle of a crisis restoration from the RAID 1 mirror split) and with mail services turned off (for a consistent and uncorrupted cyrus database). If the cron script was to be used, it would have to be disabled and then re-enabled on either side of the RAID 1 mirror split.

 

I use a different approach than the above. I have Retrospect set up to email its activity reports to me. If I come in any morning and don't see the activity report, that means that Retrospect didn't autolaunch, and I need to do the dance with the rubber chicken (delete retrorunfile, launch, then quit, Retrospect). Grumble.

 

Hope this helps.

 

Russ

[nazteq]

Very very helpful. Most appreciated.

 

I too do the rubber chicken, unfortunately my client is not interested, and I don't blame him.

 

This isn't the place to talk alternatives, but it is amazing how few there are. If only Handy Backup were available for Mac.

[Tanster]

When that script does fire and there's no one logged in, it plasters its GUI all over the screen behind the login window like daisies sprouting in a field. From a security angle, this is dangerous since all those GUI windows from Retrospect are live and clickable without the need for anybody to login and enter a password. Short of leaving the admin user logged in permanently and on screensaver lock, is there any way to prevent the GUI windows from popping up?

 

For what it's worth, I've edited the Python code in the TS_Scheduler script so that each check entry in the log file is one line instead of two (much more compact and makes it much easier to see at a quick glance which timestamp applies to which entry). But the above issue occurs even before I edited the Python script.

[CallMeDave]

Quote:

---

From a security angle, this is dangerous since all those GUI windows from Retrospect are live and clickable without the need for anybody to login and enter a password.

 

---

 

Uh, no.

 

If Retrospect launches behind the login window, and a user clicks on one of Retrospect's windows, that user is presented with an authentication dialog that requires admin credentials before Retrospect can be used.

 

There _was_ a security problem in an early release of Retrospect where the Apple menu was live, and the Previous Items submenu presented a path for applications to be run as root. But that got fixed long ago.

 

If you are seeing different behavior, please post specific steps to reproduce.

 

Dave

[Tanster]

Unfortunately, that's not true.

 

The only way to get the autolaunch script to launch via cron was to disable the requirement for admin credentials to run Retrospect itself. Otherwise, the autolaunch script wouldn't successfully launch Retrospect--you'd get this request window asking for root to provide credentials (the cron job runs as root and is entered in /etc/crontab as such by the TS_Scheduler installation process) and it would sit there forever (and I ran the TS_Scheduler installation as per instructions). So, to get the Python script to work through cron, I had to disable the authentication requirement from the Retrospect preferences.

 

Now, when the autolaunch script does fire, it pops up Retrospect, which displays its Directory window and waits for its scheduled backup script to launch. I have the autolaunch script fire a half hour before my backup scripts fire (and then the backup scripts fire successfully. Otherwise they don't fire at all.) Now, all someone has to do is quit Retrospect (which is peeking out from behind the login window) and the backup scripts either won't fire if they do this before the backup scripts are due to start or the backup scripts get aborted if they do so while they are working.

[CallMeDave]

Plese read what I wrote, and reply to it specifically:

 

"If Retrospect launches behind the login window, and a user clicks on one of Retrospect's windows, that user is presented with an authentication dialog that requires admin credentials before Retrospect can be used."

 

You are saying that if you click on one of Retrospect's windows (that is peeking out from behind the login window), you are not presented with the authentication dialog?

 

If so, then this is a failing with the non-standard launching choices you have made. When Retrospect is launched by its built-in launching process, authentication is required no matter what the settings are in the program's preferences.

 

The TS_Scheduler was offered without warranty or guarentee, an you have apparently discovered one of its limitations. Rus has offered a suggestion to work around the problem with retrorunfile that does not open the machine to another user preventing your backups from running. You'll need to chose the method that best suit your environment.

[Tanster]

Quote:

---

Plese read what I wrote, and reply to it specifically:

 

"If Retrospect launches behind the login window, and a user clicks on one of Retrospect's windows, that user is presented with an authentication dialog that requires admin credentials before Retrospect can be used."

 

You are saying that if you click on one of Retrospect's windows (that is peeking out from behind the login window), you are not presented with the authentication dialog?

 

 

---

 

Correct. That is precisely what I'm saying: Anybody can click on any button and have Retrospect respond, including the "Pause" or "Stop" buttons which show up when a backup script is running or even the "Quit Retrospect" option on the menubar in the background. I trust this is specific enough? If not, please let me know what other information you need. And if I get Retrospect to require the user to authenticate, then the script when run by cron doesn't ever complete successfully because the first thing it does is pop up an authentication window asking root to authenticate (since the effective user in the cronjob is set to root). As this is a cronjob and no admin is around when it fires, it just sits there with the authentication window displayed and no Retrospect backup script ever fires either. But if I disable authentication (see below as to how I did it), it runs fine, pesky windows notwithstanding.

 

Quote:

---

 

If so, then this is a failing with the non-standard launching choices you have made. When Retrospect is launched by its built-in launching process, authentication is required no matter what the settings are in the program's preferences.

 

 

---

 

If the script had run as advertised, I wouldn't have had to make any "non-standard launching choices." Or, if Retrospect's automated backup scripts had run as advertised, I wouldn't even have had to use Rus' script. What I did to disable the requirement for authentication is to uncheck the little box in the bottom left of the authentication window that says "Require authentication" after authenticating once as root (this is running on an OS X server). This did the trick. Disabling authentication from within Retrospect's preferences didn't do a damned thing. Nor does unchecking the abovementioned checkbox and clicking on the "Cancel" button. You must authenticate once for the disabling of authentication to take hold.

 

Quote:

---

 

The TS_Scheduler was offered without warranty or guarentee, an you have apparently discovered one of its limitations.

 

 

---

 

Yes, I know and I have. And I'm wondering how anyone else could have gotten it to run successfully since I followed the installation instructions precisely without deviation (run TS_Scheduler as the admin user, set up the cronjob, etc., all within the TS_Scheduler GUI itself--no CLI usage). I then discovered it didn't complete successfully and when it attempted to run, it only displayed that authentication window with "root" filled in as the login just behind the login window. It was only when it failed to run that I started to debug it. I didn't fiddle with it before then--I believe in the "if it ain't broke, don't fix it" school of thought.

 

Quote:

---

 

Rus has offered a suggestion to work around the problem with retrorunfile that does not open the machine to another user preventing your backups from running. You'll need to chose the method that best suit your environment.

 

 

---

 

Yes, I suppose I'll have to explore that option. Or just keep an admin user permanently logged in but with the screen protected under a screensaver lock as a temporary workaround. But what is bothering me is why his script doesn't work. Is it just my setup and have others gotten it to work without removing the authentication requirement? What am I missing here? Is this only particular to a 10.4.8 server (I've heard that some security measures have been tightened in 10.4.8 that weren't there in prior versions and am wondering if this is one of them).

[nazteq]

The dependability of auto-launching my script is now at about 10%. Amazing how bad this and that it isn't fixed. I have officially begun looking for an alternative.

[CallMeDave]

Quote:

---

The dependability of auto-launching my script is now at about 10%

 

---

 

We know that retrorunfile depends on a clean quit of the program for it to store valid information about the next required launch.

 

- Looking back at your log, is Retrospect quitting cleanly before the failure to launch? Could there be some other issue at play that is causing the program to crash or die, leading up to an un-updated schedule file?

 

Dave