Retrospect 8.2 can't find clients

[ttwm]

That's my problem:

 

Basic configuration:

- Retrospect version: 8.2 (latest)

- Server: Mac mini 2,4 Ghz, no additional software installed, completly fresh system software (10.6.3 and 10.6.5 - I've updated the OS to see if that solves my problem, but it didn't)

- I have set Retrospect engine to start-up automatically via system preferences

 

So that's what happens:

a) Server starts-up at scheduled time

Retro engine starts-up as well

c) Retrospect can't find any sources (all Macs, OS X 10.5.6) on the local network.

d) I shut-down and restart the engine via system preferences and Retrospect is able to find all the sources on the network.

 

I've already contacted the support - but all suggestions so far (re-installing, throwing away config and .plist files) did not help...

 

What I've found out in the meantime:

If I set-up the engine not to start-up automatically when the Mac starts-up and instead go to system preferences and start it up manually - Retrospect finds the sources. But that's not a solution - the server should backup at night unattended...

 

The workaround I use in the meantime:

a) Engine ist set to not start-up automatically at computer-start-up

Instead I wrote an AppleScript and put it in the start-up items. This script starts the engine via a "do shell"-command.

 

All in all I believe the engine is somehow bugged when it "starts-up too early"...

 

Any suggestions how I can solve this problem or any hints what to try next?

 

Kind Regards

Andreas Baumann

[Daniels]

Is there any reason why the server can not be constantly running?

 

Also do you launch console on start-up? The console may be launching before the engine has completely finished starting up.

[Maser]

How did you add your clients to the engine? Multi-cast or by direct IP address?

 

Is there any chance your server machine isn't getting it's IP address (via DHCP, maybe?) immediately when it starts up?

 

It does sound like a "timing" issue somewhere. I'm guessing the initial launch of the engine at system startup isn't registering the engine machine "on the network" (somehow for some reason) and that's why it's not seeing the client computers.

 

[ttwm]

Is there any reason why the server can not be constantly running?

 

Also do you launch console on start-up? The console may be launching before the engine has completely finished starting up.

 

The backup itself is done in about 30 minutes every night - I prefer to shut-down the computer the rest of the time.

 

The console is not started on start-up. In fact it isn't started at all unless I get error messages via mail.

[ttwm]

How did you add your clients to the engine? Multi-cast or by direct IP address?

 

Is there any chance your server machine isn't getting it's IP address (via DHCP, maybe?) immediately when it starts up?

 

It does sound like a "timing" issue somewhere. I'm guessing the initial launch of the engine at system startup isn't registering the engine machine "on the network" (somehow for some reason) and that's why it's not seeing the client computers.

 

Clients are addresses via multicast (we have DHCP and no fixed IP adresses)

 

I agree that it must be a "timing" issue during start-up - but what happened that for some days it worked perfectly and then the error came up?

I did not change anything on the Backup server or on the network...

 

It's nice to know where the problem occurs and how to avoid it - but it's much better to know why it occurs

 

The support could not help me at all - in fact it seems that they did not understand the problem at all.

 

The last days my work-around runs without any errors - hopefully I do not run into new problems...

[lstone19]

You're not the only one. I occasionally see this happen too. I generally try to run a small backup right after a reboot to make sure Retrospect is fully there.

 

To the OP: can you share the script you wrote to do the delayed startup?

[Maser]

How soon after your computer is started up is the script supposed to launch?

 

Are you starting the computer at (for example) midnight and have the script scheduled to run at midnight?

 

 

What if you started the computer (and engine automatically) at 11:50 p.m. and had the script run at midnight? Any difference?

[ttwm]

The Server was set to start-up at 8.pm. and the first script was set to run at 9 p.m. - so I had a one hour delay.

 

Support just wrote me:

 

After reviewing your notes, I understand that Retrospect is not detecting your clients after a server reboot.

 

- This is a known issue, after rebooting a Retrospect server, Retrospect will not communicate properly with the clients, usually getting error -530.

- This issue has been escalated to the engineering team and they are looking into a solution.

- Currently the only workaround is to stop and restart the Retrospect engine. Or as you have done, to manually start the engine after the computer has started up.

 

So lets wait and see if the can handle ist in a later release.

[ttwm]

To the OP: can you share the script you wrote to do the delayed startup?

 

Here is the Applescript (I run the AS program via startup items on server start-up):

 

do shell script "sudo /Library/PreferencePanes/Retrospect.prefPane/Contents/Resources/Retrospect start_server" user name "your name" password "your password" with administrator privileges

 

I know that it's not very elegant/secure/whatever to provide the user and pass in a script...

 

In another thread there was also the possibility to start/stop the server with the "sudo launchctl load/unload..."-command - but that is not working on my backup server (I don't know why...)

 

Regards

Andreas Baumann

[Maser]

Huh.

 

- This is a known issue, after rebooting a Retrospect server, Retrospect will not communicate properly with the clients, usually getting error -530.

 

 

This is weird. I have never seen this problem and I reboot my backup server often (at least once a week). I only use Proactive scripts, so I wonder if that makes a difference

 

Or maybe this *is* a problem, but after 20 minutes of just being up, it's *eventually* finding the clients when the proactive server keeps checking for them?

 

 

Maybe as a workaround, change your backup script to a Proactive script (which can also be set to run during a certain time period) and see if you get different results?

 

[ttwm]

Perhaps the problem only occurs on some type of machine (like my Mac mini).

 

Or you have some additional things installed which load before the Retro engine - which could result in a later initialization of the engine (as we found out, it seems to be a matter of time when the engine is starting up).

 

Clients are not found even after 8 hours - so I don't think switching to Proactive will help a lot (although I do not know whether proactive uses a different method for looking for clients on the network).

 

As the server is now doing his jobs without errors - I won't try the Proactive stuff. Never touch a running system...

 

Regards

Andreas Baumann

[Maser]

My engine machine is also a Mac mini -- a 2.0G core2duo with 4G RAM running 10.6.5 (IIRC, I rebuilt this with a stock 10.6.0 CD at one point, so it's not something upgraded from 10.5.8)

 

So I'd be surprised if *faster* hardware caused this problem (but you could determine that by maybe temporarily installing the engine and use the same config80.dat file on a slower computer and see if you can replicate this...)

 

My OS on my mini is *stock* -- the only thing on it besides Retrospect are Apple OS updates. The computer automatically logs into an account and the only login item besides the console is the iTunesHelper. "Remote Login" (for ssh) and "Remote Management" (for ARD) are configured on this, but that's it. No screen saver, nothing else.

 

 

[Maser]

FWIW, here's what my system.log file shows after I restart and by the time config80.dat has a new time stamp. Nothing seems odd to me...

 

Dec 1 14:46:51 localhost com.apple.launchd[1]: *** launchd[1] has started up. ***

Dec 1 14:46:59 localhost mDNSResponder[19]: mDNSResponder mDNSResponder-258.13 (Oct 8 2010 17:10:30) starting

Dec 1 14:46:59 localhost blued[16]: Apple Bluetooth daemon started

Dec 1 14:47:00 localhost configd[14]: bootp_session_transmit: bpf_write(en1) failed: Network is down (50)

Dec 1 14:47:00 localhost configd[14]: DHCP en1: INIT transmit failed

Dec 1 14:47:00 localhost configd[14]: network configuration changed.

Dec 1 14:47:00 ottbackup configd[14]: setting hostname to ".local"

Dec 1 14:47:05 ottbackup /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow[38]: Login Window Application Started

Dec 1 14:47:06 ottbackup bootlog[49]: BOOT_TIME: 1291232811 0

Dec 1 14:47:12 ottbackup com.apple.usbmuxd[31]: usbmuxd-207 built for iTunesTenOne on Oct 19 2010 at 13:50:35, running 64 bit

Dec 1 14:47:14 ottbackup com.roxio.RetroEngine[53]: #2> Command line is /Library/Application Support/Retrospect/RetrospectEngine.bundle/Contents/MacOS/RetroEngine

Dec 1 14:47:15 ottbackup loginwindow[38]: Login Window Started Security Agent

Dec 1 14:47:15 ottbackup loginwindow[38]: Login Window - Returned from Security Agent

Dec 1 14:47:15 ottbackup loginwindow[38]: USER_PROCESS: 38 console

Dec 1 14:47:15 ottbackup com.apple.launchd.peruser.501[95] (com.apple.ReportCrash): Falling back to default Mach exception handler. Could not find: com.apple.ReportCrash.Self

Dec 1 14:47:16 ottbackup configd[14]: network configuration changed.

Dec 1 14:47:17 ottbackup configd[14]: setting hostname to ""

Dec 1 14:47:17 ottbackup com.apple.launchd.peruser.501[95] (com.apple.Kerberos.renew.plist[123]): Exited with exit code: 1

Dec 1 14:47:34 ottbackup com.roxio.RetroEngine[53]: DAGServer:RegisterProtocal Protocal(GUID=200)!

Dec 1 14:47:36 ottbackup Retrospect[130]: [ENGINE] 8.2.0.399 connected to 'ottbackup' (127.0.0.1:22024, 8.2.0.399)

Dec 1 14:47:36 ottbackup Retrospect[130]: Warning - unable to find template matching predicate activityType CONTAINS[cd] "Proactive"

Dec 1 14:47:58 ottbackup login[149]: USER_PROCESS: 149 ttys000

Dec 1 14:47:58 ottbackup com.roxio.RetroEngine[53]: #2> Captured signal SIGPIPE!

[Camelhump]

Im getting the same thing.

 

On computer restart, retro engine starts at startup - console will not connect. I have to quit console, turn engine off and on in the system preferences, then restart console; for Console to talk to the engine.

 

Mac Mini - 2006 - 2ghz core 2 duo, 4gig RAM

 

[Maser]

Weird. I've run the engine on a number of machines and never have seen this.

 

Do you have any other software running on the engine machine besides Retrospect? Any anti-virus software? Anything else launching at login?

 

How are your media sets connected to the engine machine?

[Daniels]

The only time I have ever seen this was after a software update that required a restart. In these cases if you exit the console before doing the update the problem goes away. Other than this I have never seen this problem.

 

Have you tried closing the console and re-opening it without restarting the engine?

[Stillman]

Often Retrospect (8.2 Mac) can't find my clients. Stopping then restarting the Retrospect Backup Engine cures the problem. I have the engine automatically starting when I start up the computer and that works just fine for me. I'm running Snow Leopard on a year old iMac.

 

I hope the various glitches in this program will be fixed soon! Overall it seems to be working well.

[Camelhump]

ttwm -

I used your(?) applescript -

turned off the retro system pref to start on start up

and added your applescript to the startup items of the admin (only) login. This resolves the console/engine not talking.

 

Im guessing that the engine starts BEFORE the hardware gets an IP address and from there everything is F.U.B.A.R.

[Maser]

Yeah -- that's why I'd be curious to see the system.log startup entries from somebody having this problem. Maybe the people having this problem aren't getting their IP address fast enough from their DHCP server?

 

(I'm assuming it's only DHCP serving machines that have this problem? Though *my* backup server is getting it's *static* address assigned via DHCP -- are the machines having this problem getting non-static DHCP addresses?)

[Camelhump]

in my case - yes -

the DHCP address assigned is technically non-static.

 

In reality, the server assigns the same IP address as long as the machine is not off line for more than about a week.

 

[Maser]

What if you manually put in that IP address and reboot? Do you have the same startup problems?

[CallMeDave]

In reality, the server assigns the same IP address as long as the machine is not off line for more than about a week.

 

Here's an idea; since the Retrospect Engine host machine is acting as a server, why not treat that machine as you'd treat any other server and give it a static ip address?

 

Trying to get Retrospect to act differently is like trying to get OS X Server to just deal with not having a valid PTR record; not gonna work and the wrong direction to go.

[Daniels]

I use a static IP address with DHCP on my Retrospect machine and very rarely see this problem and usually a close and re-opening of the multicast window fixes the problem.

[Camelhump]

Dave -

eventually - when the new retroserver is functioning to my satisfaction - I am NO WHERE NEAR THAT after more than 3 months, it will replace the old one.

 

At that time it will get a static IP - however the static IP will STILL be server via DHCP; network deity requirement(s).

 

[Camelhump]

I have played with this script a bit - the solution to get a 'turn of the retro engine' is this:

replace the string "Start_server" with "Stop_server"

 

do shell script "sudo /Library/PreferencePanes/Retrospect.prefPane/Contents/Resources/Retrospect stop_server" user name "your name" password "your password" with administrator privileges

 

ive been working on trying to get the apple script to request a username and password rather than hard code it into the script. WHen I manage to get that working - Ill post it somewhere (obvious) on the forums.