Jump to content

Retrospect not launching scheduled scripts


Yoann

Recommended Posts

Using Retrospect 6.0 Multi-Server on Windows Powered (5.0 / 2000), I've had cases, happening randomly and rarely, where it simply does not start a scheduled script.

 

I keep Retrospect closed on the server and rely on the Retrospect Launcher to run the scripts automatically (1 hour lookup time). If I open Retrospect after a skipped execution, it immediately starts the missed script.

 

Any ideas what could be causing this?

Link to comment
Share on other sites

Nate,

 

 

 

Thanks for the info. How is this procedure different from just stopping and restarting the service without restarting the actual machine? This is a machine that is used about 24/7, so I prefer solutions that don't require a restart.

 

 

 

Also, after opening Retrospect after the skipped execution and cancelling the missed backup script that starts up immediately, the scheduled scripts run as usual (with Retrospect closed). I vaguely recall seeing the Retrospect Launcher service stopping whenever Retrospect is opened and starting back up whenever it is closed.

Link to comment
Share on other sites

Hi

 

I think that restarts the service. That could resolve the problem temporarily I suppose.

 

If stopping and starting the service is enough you might want to create a batch file with the net stop and net start commands to give the service a kick in the pants every once in a while. You could schedule it with the AT command or with task scheduler.

 

Thanks

nate

Link to comment
Share on other sites

I was thinking along those lines, which is why I wanted to understand the difference between restarting the service and restarting the machine with the service disabled. I'll probably do something along those lines until I can restart the machine...

Link to comment
Share on other sites

This is an ongoing problem...you'll see it in lots of threads here. Just had it happen again, myself, and came to the forum to see if the standard advice had changed. I was not surprised to find this thread near the top of the list.

 

And nothing has changed. Dantz's "Solution" is to reinstall the service. (BTW, I've never found the restart NateW recommends to actually be necessary, so if down time is a problem, or even just a nuisance, try it first without the restart...ymmv.) But it's not a solution. It's a workaround.

 

This problem has been ongoing since at least Retrospect Express 5.6 for Windows, which was when I first encountered Retrospect, at the time on Win 2000 Pro. In my system, I have Retrospect 7.0 for SBS, running on SBS 2003 SP1. Same problem, same workaround. To this day, I have to reinstall the service 3 or 4 times per year on each Retrospect machine. Although I love Retrospect's smart database, I no longer recommend Retrospect, because what good is a well-designed database if the backups don't run?

 

I am a computer consultant supporting a wide range of Microsoft and 3rd party software, including backup software. I have NEVER seen a product besides Retrospect that requires its service to be reinstalled regularly, so I don't believe it's a problem with Windows. In fact, off hand, I don't recall ever having to re-register a service. I believe it's a problem with Retrospect.

 

Dantz knows it, too, because they've been giving this same advice over and over for years, now.

 

Why hasn't this been fixed after all this time??

Link to comment
Share on other sites

JeffV,

 

So this problem has followed you around all the way from Retrospect 5.6? That is very odd. Is there anything that you do on _all_ of your computers? i.e. certain configuration settings a specific software package etc. I'm wondering if there isn't something specific in your environment that trips up the launcher service.

 

FWIW Problems with the launcher service are actually very rare. There have been a few threads about it in the past but investigations found nothing conclusive as to the cause.

 

Thanks

Nate

Link to comment
Share on other sites

Although I only installed Retrospect on a single computer, I'm guessing that whatever package he installed to trip up the service I would have to have on my server as well.

 

This is my exact setup:

- Dell PowerVault 725N with 2.5 GHz Pentium 4 / 1 GB RAM

- Microsoft Windows Powered 5.0.2195 Service Pack 4 Build 2195

- All Windows & Windows Installer patches and service packs

- Broadcom Management Programs

- Dell ActiveArchive

- Dell OpenManage Array Manager

- Dell Hard Drive Diagnostics

- Linksys PrintServer Driver

- LiveUpdate 1.7

- Microsoft Server Appliance Kit 2.0 Add-on Pack

- Microsoft Server Appliance Kit Add-on Pack Language Kit

- Microsoft Server Appliance Kit Language Setup Wizard

- Microsoft Server Appliance Kit Setup Wizard

- Norton AntiVirus Corporate Edition (7.6)

- Persistent Storage Manager Language Setup

- Retrospect 6.0

- Sony Tape Utility

 

Nothing changes on the server when the service stops working.

Link to comment
Share on other sites

I don't have the open file option. I used to have it before I ran a server, with RS 6.5 Pro. But it did not cause shutdown problems for me.

 

May be something to the SAV/NAV connection though...so are you dumb enough to remove NAV and see if it fixes it? Because I'm not dumb enough to remove SAV!

Link to comment
Share on other sites

I've removed and put NAV back a few times, but never for extended periods of time. This problem appears so randomly and rarely that I'd probably have to go one year without NAV before confirming if that was the problem. Unfortunately, I can't do that...

Link to comment
Share on other sites

Hi

 

This is interesting. NAV is so popular though I think that this problem would affect far more people if there were something in the updates causing problems.

 

I wonder if a service on the machine isn't clobbering the Retrospect launcher service from time to time or if a virus scan doesn't corrupt it. Can you remove the Retrospect directory from scheduled virus scans? Or at least the Retrospect Executable and bedrock.dll file?

 

Another alternative albeit a messy one...

Create a "dummy script" that backs up an empty folder to a file backup set. Don't set a schedule. Then go to the run menu at the top of the Retrospect screen and create a run document choosing Recycle backup. This will create a shortcut that you can save somewhere. Clicking the shortcut will launch Retrospect and run the script.

 

Use the windows task scheduler to launch this shortcut file every day at a set time. This will make sure Retrospect gets launched so that your other scripts can run.

 

Like I said, messy but it may be worth the piece of mind.

 

Thanks

Nate

Link to comment
Share on other sites

While I have NAV installed on the server, it's running with realtime protection shut off. It'll only scan files during manually scheduled scans, which occur on weekends when there are no backups.

 

Now, the failed instance this time was on the following Monday, but I can't recall if that's always been the case. Plus, I'm not sure why the Launcher would get corrupted when it shouldn't be doing anything during that time anyway (or for the next 24 hours when it has only a lookahead of 1 hour).

Link to comment
Share on other sites

Even without realtime scanning, there are other background operations...for example LiveUpdate or DefWatch doing their thing, loading config changes pushed from SSC, etc.

 

But I gotta agree that a NAV/SAV/Retrospect problem is unlikely.

 

"Uninstalling" and "reinstalling" the Launcher service amounts to deleting and replacing a registry branch...right? HKLM\SYSTEM\CurrentControlSet\Services\RetroLauncher (And maybe RetrospectHelper...haven't looked to see if they're created & deleted at the same time.) If so, if "resinstalling" fixes the problem, that registry branch has to be where the problem is. That would pretty much exhonerate NAV/SAV, I'd think.

 

Next time this happens to me, I'm going to try to remember to export that branch before and after the "fix" and WinDiff them. Don't know if I'll learn anything but it couldn't hurt.

Link to comment
Share on other sites

I agree about the background processes, but what I was getting at was that NAV wasn't touching anything within the Retrospect folder on a realtime basis (which was what Nate suggested I exclude from the scans).

 

Disabling the service certainly does not delete the Registry key you mentioned. I don't even see how a restart would cause the service to get reinstalled, unless what Nate meant was that Retrospect must be launched after the restart to reinstall the service. If that's the case, maybe when Retrospect launches and sees that the service has been disabled, it "reinstalls" it... I'm not sure if that means recreating the Registry key or doing some other Retrospect db changes.

 

This being a live server, I can't really mess with it to see what different things do. So, for now, I'll probably just deal with it until Dantz can figure out a solution.

Link to comment
Share on other sites

> Disabling the service certainly does not delete the Registry key you mentioned.

 

 

 

No, of course it doesn't. Disabling just modifies the Start value. But if you re-read NateW's initial response, you'll see disabling & re-enabling the service is not the workaround!

 

 

 

Uninstalling the service--which is what happens behind the scenes when you turn off the Launcher in Retrospect preferences--DOES delete that branch. You'll also see the service disappear from Services.msc. Re-enabling the Launcher in Retrospect then re-creates the branch.

 

 

 

From Windows' perspective, the service has been uninstalled and reinstalled. And since the Launcher then starts working again (IME), that's how you work around this problem.

 

 

 

Installing & uninstalling a service is a very unusual way for a program to enable and disable its features, but since it gets messed up from time to time, it's kind of a good thing they did it this way.

 

 

 

Nate's suggestion to restart in between would be important only if the Launcher service was hung. If Windows can't stop the service, it won't delete it, either. And that seems to be part of the key to the workaround. But IME, Windows is generally able to stop the Launcher service so the restart is not necessary. So my approach has been to try it without the restart since restarting servers is a nuisance. If that doesn't work, then try it Nate's way. YMMV.

Link to comment
Share on other sites

My bad, I misread as disabling the Launcher service via Services.msc instead of via Retrospect. The workaround makes more sense functionally. Yet, from a development standpoint, the fact that deleting and re-creating a service Registry key fixes the problem doesn't make any sense.

 

That Registry key tree is used by the Service Control Manager to, well, control services, but, when I experience the problem, the Retrospect Launcher service is running just fine. The SCM doesn't take any actions by itself, unless there are restart conditions set (none for the Launcher service). It also doesn't change values in that Registry path unless service properties are manually changed (which isn't the case). Essentially, deleting and recreating that key doesn't impact the service files and related database, although it does have the effect of "restarting" the service.

 

That brings me to my next point. As I mentioned in one of my earlier posts, opening Retrospect and closing it fixes the problem. From what I've seen, opening Retrospect stops the Launcher service, and it gets restarted when Retrospect is closed. So, I wonder if disabling/re-enabling is even needed at all. It looks like all the Launcher service needs is a restart.

 

Of course, that still doesn't explain WHY it needs a restart in the first place.

 

Just my thoughts on the issue...

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...