Jump to content
Sign in to follow this  
rudar

Clients not visible?

Recommended Posts

I have Retrospect server 5.0.236 and the clients are at 5.0.540. This was working fine last week, but now the server is reporting that the clients are not visible on the network (error -1028 if I try configuring the client.) To rule out network problems, I fired up the network utility on the server machine and port-scanned the client; not anly is it visible, but port 497 is all open and ready for action, and the Retrospect application on the client is turned on.

 

 

 

Any ideas? I tried seeing if there's a newer server build out but my license key was not accepted... Anyone know if there is?

Share this post


Link to post
Share on other sites

I am having the same problem. THe network view shows them responding but when I try to configure them or back them up I get the same error...

 

 

 

Even after a restart....

 

 

 

Anybody?

 

 

 

Thanks,

 

Ric

Share this post


Link to post
Share on other sites

Yes, I'm having the same trouble. My Mac server is running 5.0.236 on OS 9.1 and my client is running Retro Client 5.0.540 on OSX10.2. The client is visible in the network, but it won't back up and it won't configure.

 

 

 

Help!

 

 

 

Thanks,

 

Gary

 

 

Share this post


Link to post
Share on other sites

I have been having a LOT of trouble with this since applying the last two updates. In my case, I can see that the server loses contact with the client while scanning (shows 'File/Folder Not Found', then Net Retry warning appears) and then gives up.

 

 

 

Meanwhile, though, the client still 'thinks' it's being scanned (shown in its status pane) and freezes, waiting forever for the scanning to finish.

 

 

 

So, the next time the server tries to back it up, the client reports that it's busy (producing a 'Client Reserved' message in the error log.) The client still shows up as 'responding' in the server's client list, but can't be backed up.

 

 

 

Once the client has frozen this way, it's impossible to recover by clicking its 'Stop' button. MacOS X's 'Force Quit' command won't solve the problem either, because the client's background process is still running. The only choices are to restart the client machine, or to use Process Viewer to identify the process ID numbers of the 'pitond' and 'retropds.22' processes, and then kill them using the Terminal. (You can't use Process Viewer's 'Quit Process' command because they're owned by root.) 'sudo kill [process ID #]' will kill pitond, but you have to use the 'sure kill' option -- 'sudo kill -9 [process ID #]' -- to get rid of retropds.22.

 

 

 

Once you've done all that, you can restart the processes by opening the client pane and clicking the 'On' button, and now the client will no longer be 'reserved.'

 

 

 

But you still won't be able to back it up, because the exact same cycle will happen the next time you try it -- or at least that's been my experience so far. Obviously, this is very frustrating!

 

 

 

I'd like to try to isolate the problem by 'backdating' to previous client and server versions until I find one that works, but Dantz' download site only shows the latest updaters. Does anyone know if the older ones are available somewhere?

 

 

 

TIP: If you think you might be having the same problem, but don't want to initiate a backup to see, you can try to browse the client volume from the server. This will trigger the same cycle of 'File/Folder Not Found'... net retry ... client lockup ... 'Client Reserved' error message.

Share this post


Link to post
Share on other sites

Update to above: I worked on this problem some more over lunch and traced it to a 'strange' folder on the client machine (running MacOS X 10.1.5)

 

 

 

I determined this by 'forgetting' all the subfolders on the problem volume, then defining subfolders one by one and browsing them until I hit one that triggered the 'hang' behavior described in the post above.

 

 

 

Then (after going through the tedious 'kill' procedure mentioned to get the Retro client working again) I'd 'forget' the problem subfolder and start defining subfolders inside IT until I hit a bad one... etc... etc.

 

 

 

Unfortunately, I couldn't figure out what might have been wrong with the 'strange' folder. It had a # in its name, but I tried deleting that and it still hung the client. Its permission settings weren't unusual. And once I made a new folder, copied the 'strange' folder's contents to it, and deleted the 'strange' folder, Retrospect started behaving itself again.

 

 

 

So, strictly speaking, I guess this wasn't a Retrospect-CAUSED problem... although it suggests that Dantz needs to do some work on error-handling in the X client!

 

 

 

Others having problems with clients freezing while being scanned (and subsequently showing as 'Responding' but still inaccessible to the server with 'Client reserved' errors) might want to try this same "selective browsing" procedure to see if an 'evil' file or folder is causing the trouble...

Share this post


Link to post
Share on other sites

WHen I have this problem, the clients machines are fine..they continue to work (ie, no user freezing or interuptions).

 

 

 

What I have is that after restarting the server several times (MacOS X 10.2), Retrospect server can eventually start backing up the clients again. Retropsect will continue to function for a couple of days.

 

 

 

On the second or third day all clients return a "client not visiable on network. When this starts happening, I can access Retrospect Server, navigate around the program, and see that they are responding. But I can't back them up or configure them. Also, when I try to quit Retrospect, I get the spinning beach ball indefinitely.

 

 

 

I then have to force quit Retrospect, and restart several times until the "client not visable" disappears and backukp continue normally.

Share this post


Link to post
Share on other sites

In reply to:

Once the client has frozen this way, it's impossible to recover by clicking its 'Stop' button. MacOS X's 'Force Quit' command won't solve the problem either, because the client's background process is still running. The only choices are to restart the client machine, or to use Process Viewer to identify the process ID numbers of the 'pitond' and 'retropds.22' processes, and then kill them using the Terminal.


 

 

 

There's another choice.

 

 

 

Hold the Command (Apple) key while clicking the "Off" radio button. This will kill pitond and will put "Not Running" in the Status message area.

 

 

 

 

 

Dave

Share this post


Link to post
Share on other sites

I am having this problem with one client. I am a little confused as to how no one from Dantz seems to have an answer or even a suggestion about this problem. I have restarted my server several times, but this one client refuses to budge.

 

 

 

Any suggestions would be appreciated.

 

 

 

klowy

Share this post


Link to post
Share on other sites

I found this approach quite useful although for a slightly different reason. I had one client machine which kept timing out with a 'Net retry' message whilst scanning the folders/files. It would give the same message using the Browse volume function and I discovered that killing it on the server machine when the message happened there allowed me to get a good fix on where the problem lay. I only started to get the problem when this particular client was updated to OS X.2.2 and this technique showed the problem to be the updated Stickies.app. There was clearly somethng wrong with this as even the Finder got into a loop trying to Get Info on the app. Attempts to fix problems with Disk First Aid and then to delete the app lead to a trashed disk. This was restored from the X.2.1 backup and the update reapplied and so far all is well.

 

 

 

It does suggest though that checking the disk structure is OK is a vital part of trying to troubleshoot these sort of problems.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×