Retrospect slows down entire computer with Tiger!!!

[scotty321]

There seems to be a SERIOUS incompatibility between Retrospect & Tiger (both 10.4.0 and 10.4.1) that is causing us a tremendous amount of grief over here. Ever since upgrading to Tiger (this was an "ERASE & install" of Tiger) and a fresh install of Retrospect 6.0.212, we have had tremendous slowdowns on our machine that do not disappear until we restart our machine. The machine slows to a CRAWL. This starts happening AFTER Retrospect kicks in for a backup on this machine. We are running the latest version of Retrospect (version 6.0.212), and it appears like somebody on MacFixit has pinpointed these awful slowdowns to the RetroRun startup item. We are backing up just this one machine, so the full version of Retrospect (not Retrospect Client) is on this machine.

 

The full story on MacFixit is located here:

http://www.macfixit.com/article.php?story=20050606093324679&query=retrospect+tiger

 

If you can't get to that page, here is the full text of the story:

Problems with Retrospect 'RetroRun' startup item -- causes unresponsiveness Users experiencing sudden system unresponsiveness under Mac OS X 10.4.x should check for errant items located in the /Library/Startup Items folder.

 

One such item identified as a potential cause of system slow-down, and eventually full blown unresponsiveness, is the RetroRun component of Dantz' Retrospect.

 

MacFixIt reader Zach writes:

 

"When Retrospect's RetroRun is enabled as a startup item, my Mirrored Door Drive (aka Wind Tunnel) Dual 1 GHz G4 Powermac becomes unresponsive on a daily basis. Specifically, what happens is that the frontmost application suddenly stops responding, with the spinning beachball/busy cursor appearing. Soon after, all other applications become unresponsive. No applications can be launched, quit, etc. (although the mouse still works). Attempting to launch an app results in an infinitely bouncing dock icon, plus a helpful 'proc: table is full' message in the system.log. This led to me look for a process usage overrun.

 

"By leaving Activity Monitor open, I have repeatably captured the cause of the unresponsiveness: at some point, very suddenly, literally hundreds of cron processes spawn, all owned by root. The specific point of onset is variable, anywhere from 1 hour to 24 hours after reboot. By trying many different system configurations, I've narrowed down the root cause to Retrospect's RetroRun. When it is disabled (i.e. removed from /Library/Startup Items), the problem does not occur.

 

"I'm running the very latest Retrospect, 6.0.212 (the Tiger version), with the latest drivers and clients. This problem has consistently occurred under both Mac OS X Tiger 10.4.0 and 10.4.1."

 

==============

 

Can somebody at Dantz please fix these problems?? We cannot get any work done because we are constantly restarting our machine twice a day. This is driving us crazy.

 

Thanks,

Scott

[CallMeDave]

Are you Zach? If so, that makes just one report (something MacFixIt has always been willing to do).

If you're not, knowing the specifics of your situation would be a helpful addition to Zach's report.

 

- For example, if you disable "automatically launch Retrospect" from Special->Preferences->Notification will the problem still occur?

 

 

>By trying many different system configurations, I've narrowed down the root

>cause to Retrospect's RetroRun. When it is disabled (i.e. removed from /Library/Startup Items),

>the problem does not occur.

 

It would be interesting to learn the methodology used to "narrow down the root cause" of this. Since retrorun doesn't use cron (at least I know it didn't before 6.0.212; I'm still on Panther myself), the observed association between the two unix processes would be interesting to know.

 

>When it is disabled (i.e. removed from /Library/Startup Items), the problem does not occur

 

Remember that if Retrospect's preferences are set to auto-launch, a fresh copy of retrorun will be placed in /Library/StartupItems/ the next time the program is launched.

 

Since more users aren't reporting this, the best thing you can do is provide clear steps that can reproduce this on a test machine. That would include a description of your hardware, and specific information about exactly what you're doing.

 

Dave

[scotty321]

No, I am not Zach, but his report made me realize that I may not be going crazy over here.

 

Let me do some more research using the suggestions you gave, and I will see if I can narrow down the problem further.

[scotty321]

Yes, I have looked into this more and apparently Dantz did not program Retrospect to play nicely with Tiger. Remember that this is on an "erase & install" of Tiger. Every time after Retrospect kicks in, the kernel_task process, owned by root, jumps up to taking 1.17 GB of virtual memory. It slows down the entire machine. A restart fixes it. Can you please help, Dantz?

[derekryan]

If you need help from Dantz you have to pay for it:

 

For customer that have an existing EMC Dantz support agreement or purchased Retrospect from a Dantz reseller:

 

Customer Service

 

North America and Other Countries

Telephone: 800.225.4880

Fax: 925.948.9099

 

Monday–Thursday, 6:00 am–5:00 pm Pacific Time

(Holidays Excluded)

Friday, 6:00am–4:00pm Pacific Time

(Holidays Excluded)

[scotty321]

Hey Derek, Go [censored] yourself. I'm reporting a bug to Dantz that they need to fix. I'm not paying for [censored]. I've already bought the software that doesn't work.

[CallMeDave]

Quote:

---

I'm reporting a bug to Dantz that they need to fix

 

---

 

Well, if that's what you're trying to do, you're doing a poor job of it.

 

Accurately reporting a bug requires providing steps to reliably reproduce it. This includes a full description of the hardware/software being used, so the software engineers can see the defect while the program is running in its debugger environment.

 

If you've "looked into this more" it would be helpful to provide whatever information you have learned. So far you haven't garnered readers of your posts with very much trust in your methods.

 

Yeah, yeah, go [cencored] myself. Way to move the conversation forward...

 

Dave

[derekryan]

I am NOT trying to offend anyone here Scotty321. I just simply wanted you to know, that I feel you will not get much of a help on this forum (maybe because not many people have same config as you have. I posted more than a week ago something myself about "unrecognized content" on the DDS4 tapes and I'vo got ZERO responses. I thought that NOBODY is using DDS4 tapes anymore. So, I did some research and bought 3 external firewire VXA-2 drives ($1500 each) but I am thinking what software should I use with it?

 

When I read about possible problems users have with Tiger and Retro I like retro less and less since I NEED to be able to READ back my tapes.

 

I wish you that you will solve your issues. Good Luck

Derek Lambert

[scotty321]

Okay, great news -- this problem was fixed with 10.4.3. Looks like it was an Apple problem!! It is now SOLVED!!!! All of our computers are now running at full speed again, thanks to 10.4.3.

[CallMeDave]

Quote:

---

Looks like it was an Apple problem!! It is now SOLVED!!!!

 

---

 

Perhaps this would be a good time to apologize to derekryan for your nasty comment to him (when he was just trying to be helpful).

 

And maybe a nice note to Ric Ford at Macintouch, telling him that this was an Apple problem, since he managed to get sucked into your assertian that you _knew_ that this was caused by Retrospect.

 

And maybe, just maybe, it was the upgrade _process_ that fixed your issue more then the new version did; you never provided a good sense that you'd done a reasonable amount of testing before stating that you'd proven anything.

 

Maybe that's why the link you provide to the Apple discussion board did little to confirm what you were reporting here and on Macintouch.

 

Dave

[scotty321]

Or perhaps it was my persistence on getting the issue widespread that caused it to be fixed. Apple reads MacFixit & Macintouch. Others confirmed the same behavior as me, including the editor at MacFixit who talked about it in his podcast. I knew 4 people personally who had the same problem. Two people on that Apple discussion board, whom I have never spoken to before, also had the issue. Retrospect confirmed portions of my problem (console.log errors whenever Retrospect launched) and fixed them in the latest release of Retrospect. Apple apparently fixed other errors that contributed to the problem as well. Looks like it was probably a combination between Retrospect's latest release & Apple's latest release that fixed the problem. It was probably 50% Dantz's fault & 50% Apple's fault. Yes, I extensively tested & tried to troubleshoot the problem 7 days a week, including erasing & installing Tiger.

[CallMeDave]

Quote:

---

Retrospect confirmed portions of my problem (console.log errors whenever Retrospect launched) and fixed them in the latest release of Retrospect.

 

---

 

I'm looking through the 23 posts you've made on this Forum, and I don't see anything to suggest that you were able to provide information to Dantz that allowed them to confirm anything.

 

In fact, I see numerous requests (from me and others) for you to provide complete hardware/software information relating to the system(s) you saw the error on, and such information was never forthcoming. The same for the thread on the Apple discussion board that was posted on Macintouch; requests for complete system information was ignored.

 

One major thing that Dantz fixed in 6.1 was how Retrospect worked on systems booted from a RAID; perhaps your system has this, but since you've never provided complete hardware specs there's no way to know.

 

> It was probably 50% Dantz's fault & 50% Apple's fault

 

You just made this up. You have no idea either what the cause was, or what the fix was.

 

> Two people on that Apple discussion board, whom I have never spoken to before, also had the issue

 

You must bet talking about a different discussion thread then the one you provided to Mac fixit. In this thread there are some posters who have the problem under discussion (word hanging) who report that they _don't_ run Retrospect, one post from someone who _did_ run Retrospect and did not have the problem under discussion, and one poster who said simply that he stopped using Retrospct and his problem went away. Nowhere on that thread is there any specific information that could confirm your theory that Retrospect alone (and not some specific configuration issue) was the cause.

 

> I extensively tested & tried to troubleshoot the problem 7 days a week,

>including erasing & installing Tiger.

 

And yet you were never willing to include complete system information in your public reports, thus making it impossible for other community members to attempt to recreate your experience.

 

It's good news that your system(s) are stable. But if Apple fixed something that was causing Retrospect to misbehave on your system configuration, then that's all the more reason for you to apologize for your previous rants against Dantz.

[Mayoff]

Scott, I am happy the issue seems fixed. I agree that if you really care about the Macintosh community then you will post an update to MacFixIt and Macintouch. In the end it will help a lot of people to know how to fix a problem you blamed Retrospect for causing. These new sites value your input. Wouldn't it be nice to post good news for once?

[tweekme]

Folks, this issue is NOT fixed with 10.4.3...

 

While it IS much better, it is not entirely gone.

 

If I remove retrorun from startupitems, and disable "automatically launch Retrospect" from Special->Preferences->Notification, I see absolutely NO slowdowns. I can reliably reproduce this issue. If I run MPEG Streamclip, and batch transcode a bunch of movies, I can transcode at 2:1 speed all day long. Right after Retrospect runs, it slows to 1:1 or slower. If I don't run Retrospect at all for several days, MPEG Streamclip never slows down. If I disable "automatically launch Retrospect", launch Retrospect and leave it launched, and kill the retrorun, MPEG Streamclip never slows down either. I ran retrospect for several days like this, with no slow downs.

 

I leave retrospect launched all the time, and go to Terminal and kill the retrorun PID. For some dumb reason, even with "automatically launch Retrospect" disabled, Retrospect still kicks ON the retrorun.

 

So, confirmed, it IS retrorun causing this.

 

system config:

G4 MDD 1.25DP, 2.5GB RAM, External AIT2 FW drive, Retrospect 6.1.126

 

Thanks, Scott K.

[CallMeDave]

Quote:

---

For some dumb reason, even with "automatically launch Retrospect" disabled, Retrospect still kicks ON the retrorun

 

---

 

Retrospect will always start the retrorun process when the application launches. If the preference to auto-launch the program is not on, the retrorun process will be killed when the program is quit.

 

While I don't know for sure the exact reason for this (it could be security related, as retrorun is a powerful root process that will die if, at any time, the host Retrospect application is moved or modified) it's very doubtful that it's dumb.

 

The test that I don't hear you say is:

 

- Configure Retrospect for auto-launch; run once and quit.

- Confirm that retrorun is alive, and Retrospect is not running.

- Test for speed.

- If speed is slow, kill retrorun.

- Test for speed again.

 

This would isolate the unix process from the Retrospect application for the test.

[tweekme]

CallMeDave,

 

Thank you for the reply...

 

Just to let you know, retrorun is NOT Killed when Retrospect quits, when "automatically launch Retrospect" is disabled. It stays alive. Which is odd, I think.

 

Also, I did just run the following test, as you wanted:

- Configure Retrospect for auto-launch; run once and quit.

- Confirm that retrorun is alive, and Retrospect is not running.

- Test for speed.

- If speed is slow, kill retrorun.

- Test for speed again.

 

Answer: speed never got slow. It slows only when Retrospect actually runs a script sequence with retrorun running. If I launch Retrospect, leave it open, Kill retrorun, and let the script run, all is fine. NO slowdown. I have been doing this for several days now. No slowdowns at all.

 

So, it seems it is retrorun causing this slowdown issue, only if Retrospect runs thru a script sequence.

 

Thanks, Scott K.

[CallMeDave]

Quote:

---

Answer: speed never got slow. It slows only when Retrospect actually runs a script sequence with retrorun running.

 

---

 

...Sound of head exploding...

 

From the above, it sounds as if you are reporting that _during_ the time Retrospect is executing a script, other processes on the machine suffer a speed hit.

 

Is that what you are reporting?

 

If not, then the previous steps should be slightly modified to be:

 

- Configure Retrospect for auto-launch.

- Configure a (small data set) script to run a few minutes in the future.

- Confirm that Retrospect's "Unattended" preference is the defalut of Quit after a script runs.

- Quit Retrospect, watch it launch, run the script and quit.

- Test for speed.

- If speed is slow, kill retrorun.

- Test for speed again.

 

But before doing this, the report that retrorun stays alive even when it's configure not to auto-launch should be the first thing you address; this just isn't expected behavior.

 

Test one:

 

- Configure Retrospect to automatically launch (Special/Preferences/Notification/)

- Launch Activity Monitor; filter by "retro"

- Note the PID (Processor Identification) number of retrorun

- Quit Retrospect; observe that retrorun continues with the same PID

- Launch Retrospect; expected behavior is that the instance of retrorun that had been running (under the PID noted above) dies, and a _new_ instance of retrorun launches, with a new PID

 

Is this what happens for you?

[tweekme]

No. The speed hit occurs just after the script finishes, and Retrospect quits. Once it is quit, the slowdown begins. If I Kill retrorun, it is still slow. Only a reboot, will bring the system back to full speed.

 

If, however, I disable "automatically launch Retrospect", quit Retrospect, launch it again. Then kill the retrorun, and leave Retrospect launched, it will NOT slow down.

 

I don't understand, why retrorun needs to launch it one disables "automatically launch Retrospect". Is there something else retrorun does? Because I Kill it, and Retrospect runs fine for days.

 

Also, as I noted before, retrorun does get killed upon quitting Retrospect with "automatically launch Retrospect" disabled. My bad on that one. Sorry for any confusion.

 

Thanks, Scott.

[tweekme]

In addition what I and many of my clients I service would like to see is a fix to the slowdown of there systems from retrorun in an Enabled "automatically launch Retrospect" scenario.

 

This has been an ongoing issue since OS 9 versions of Retrospect. Leaving Retrospect launced all the time is not a great option.

 

Thanks,

Scott K.

[CallMeDave]

Quote:

---

This has been an ongoing issue since OS 9 versions of Retrospect

 

---

 

Oh my. I was with you all the way to this statement.

 

The unix process that is used for OS X is totally different from the INIT that was used in the "Classic" Mac OS versions of the program. And I've never heard any other reports of this being "ongoing" from versions of Retrospect running in OS 9.x (a link to any existing threads might prove helpful).

 

To be honest, I'm suspicious that you actually performed the last set of tests I suggested, and that your most recent report "Once it is quit, the slowdown begins. If I Kill retrorun, it is still slow." has been provided from memory.

 

The idea that killing retrorun has no effect, and that a system restart does, seems to point _away_ from retrorun as the culprit. There's nothing to suggest that killing retrorun leaves anything behind in the system that can only be cleared by rebooting.

 

But this is above my pay grade. I'd suggest, at this point, that a support incident with Dantz is in order. Especially if you can reproduce it reliably, with steps and a configuration that they can use to attempt to recreate it.

[tweekme]

CallMeDave,

 

thanks for all your input on this issue. I do appreciate it.

 

I did indeed run that last test. As a matter of fact I have done that test since I began using every Retrospect version in OS X.

 

If I completely stop using Retrospect, my systems can stay booted for months without any slowdowns. Bring Retrospect in, with retrorun running, and it slows down after on evening. Run Retrospect without retorun: no slow downs for over one week of nightly script runs, so far.

 

Retrorun IS causing something to slow down my G4 & G5 systems. And, killing it after a script run does not fix it. I think it is a combination of retrorun, Retrospect and other applications or processes that are open on my systems.

 

Also, many others have reported these issues on MacFixIt.com and other forums. EMC/Dantz needs to get to the bottom of this. Retrorun should be able to be run without affecting the performance of the OS.

 

 

Thanks, Scott K.

[CallMeDave]

tweekme, are you the same user as scotty321 ?

[tweekme]

No.