Jump to content

How Do I Stop The OS X Client from Turning Off


Recommended Posts

I am running Retrospect 5.0 Workgroup on an OS 9 machine. I have two OS X clients. I have a small problem that often prevents me from getting a good backup of these machines. Whenever Retrospect is finished backing up these machines it turns off the client. I then have to remember to go a physically turn the client back on if I want these machines to back up the next night. Is there a setting I am missing?

 

 

 

I read in the documentation that the OS X client is supposed to run in the background as a daemon. However, the only way I can get Retrospect to see the client is to actually launch the client myself and then hide it. This is fine other than the above stated problem. Does anybody have any suggestions? I don't mind having to start the client myself if I can at least get it to quit turning off after each backup.

 

 

 

I have a feeling that the problem is in my script where I have Retrospect set to shut down clients after backup. If that is the case I will have another problem. I need that setting for my OS 9 machines. Is there some way to have it active for OS 9 machines, but not OS X machines if that is what is causing my problem?

Link to comment
Share on other sites

I do not have classic running on either of the OS X clients. The client startup folder is in /Library/Startup Items. The client application is always on. However, within the client application you have an "on" button and an "off" button. After the backup of the OS X client is complete the "off" button is automatically set. That is what is causing the problem.

Link to comment
Share on other sites

Howdy,

 

I've been working through this same problem with Dantz for the last few days. Despite the fact that the problem si highly annoying, I've got to say that I've been pretty pleased with the speed with which they have escalated the problem and have moved to help.

 

 

 

So far, we don't have a resolution, but I can tell you what is happening. 17 minutes into the connection between an OS 9 Retrospect server and an OS X Retrospect Client, the connection aborts with a client-side UNIX Signal. It's unclear from the infromation available right now whether Retrospect is posting the signal to itself, or if the signal is being posted by some portion of MacOS X. However, it is most likely happening under the control of some timeout or keep-alive process, as 17 minutes is suspiciously near to 1024 seconds.

 

 

 

So, I have non-OS X machines backing up to the server and they all work fine (os 9 and Windows). At the request of Dantz, I set up a separate server on OS X. This copy talks to all of my clients correctly (OS 9, OS X, and windows).

 

 

 

This isn't a great solution for me, because I have SCSI problems right now with the SCSI controller connected to my tape backup unit (that's another story, and it's clearly Adaptec's fault), but I am backing up my OS X machines to a separate (non-tape) backup and it is working just fine.

 

 

 

I'll keep the forum up to date on anything that I find out. For the time being, the best work-around appears to be using OS X to backup OSX clients (and it appears to work just fine for OS 9 as well).

 

 

 

Good luck,

 

-Gaige

 

 

Link to comment
Share on other sites

greetings,

 

 

 

I don't know that it is related to OS 9. I am experiencing similar behavior on my LAN (4 OS X clients & 1 win2k client, backed up via Retrospect Workgroup running on OS X Server). I have no OS 9 machines, and made sure to delete my OS 9 client software when I upgraded to RW5. frequently, R client is turned off on my OS X machines. I thought it was related to putting them to sleep, but now I'm not sure - it almost appears random. it is not happening immediately after a backup session (currently 10am daily) but sometime over the night, the gremlin sneaks in...

 

 

 

not sure if that helps, or hinders. I can try to do some more guided testing, if necessary.

 

 

 

-tim

 

 

Link to comment
Share on other sites

I'm having a similar problem, where Mac OSX clients seem to 'disappear' from Retrospect at the time of the backup. What I mean by this, is that they are visible and active in the 'Clients' section of Retrospect before and after the backup. For some reason, when the automated backup gets to these machines, it gives up, and logs an error that the client was unavailable.

 

 

 

This isn't consistant, and only happens maybe 2/5 of the time. After it does, I usually restart the OSX client machine, and relaunch the Retro Client on it. I then go to Retrospect to the client section and go to configure the client, just to make sure its responding, which it is. That usually gives me 1 or more day(s) of backups until it happens again.

 

 

 

However, once in a while, it will miss a day, then just start working again, even after the restart. For example this last weekend. We do 3 backups (one each day) over the weekend unattended. It missed the Sat am (and the machine was restarted on Fri night), then started working for Sun and Mon morning.

 

 

 

It also seems to happen with one of our OSX clients more often than the others.

 

 

 

Kind of weird, but wish it just worked so I didn't have to worry about it.

 

 

 

-Steve

 

swilkinson@macys.com

Link to comment
Share on other sites

well I have (for now) solved all of my network troubles between RW5 and its clients. each one of my OS X clients was doing something different! one was turning off its Client software with every restart, another was visible to RW5 everywhere EXCEPT during backup (stalled on Net Retry despite Responding in the Clients panel). yikes! so here's what I did for each OS X client, and my setup has been stable so far (through one backup session and multiple restarts):

 

 

 

1. on the client machine, I made sure I had no copies of OS 9 client software hiding, then ran the OS X client installer and chose Uninstall.

 

2. went to the backup machine (OS X Server) and "Forgot" the client.

 

3. went to the client machine and ran the client installer again, this time installing the client software.

 

4. immediately restarted the client machine after installation.

 

5. went to the backup machine and reconfigured the client.

 

 

 

hth (and hope this lasts!),

 

 

 

tim

 

 

Link to comment
Share on other sites

Well, my problem was solved this afternoon after some pretty extensive work with the technical support folks at Dantz. We finally narrowed it down to the setting requiring the speed threshold. Once I removed it (set it back to 0), the systems stopped turning themselves off.

 

 

 

Dantz can now reproduce the problem in house.

 

 

 

-Gaige

 

 

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...