Jump to content

Retrospect 8.2 can't find clients


ttwm
 Share

Recommended Posts

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

B) 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

B) 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

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...