Jump to content

Latest Issue - Can't communicate


Recommended Posts

I have one (client) server that the BU server is now unable to communicate with - it can't "see" it on the network.

 

I restarted both servers (client and BU server); I reinstalled the client.

 

Nothing.

 

Ready to give up on this product.

Edited by Guest
Link to comment
Share on other sites

What happens if you try the "test" option in the client source screen with the IP of that client?

I'm not sure were the "test" option is, I couldn't see it in the Sources toolbar, or in the interface in the add client sheet.

 

I also looked in the menus and the activity buttons

 

But I did trying browsing the hard drive from the sOUrces list, and it says "Source unavailable"

 

I also tried the "Refresh" button, and I get "Source unavailable"

 

What happens if you add this client by IP address?

If I go to add source, enter its IP address, type in the password, I get a green check next to the "Add" button.

 

 

When you open the client software, what status is displayed? Does it say "ready"?

Yes.

 

I know that IP/DNS is working, because if it wasn't the server wouldn't work at all - it is a staff home folder server, and if DNS isn't working, nothing works!

 

Also I can resolve both the client's IP address and the domain name from the backup server, and the check IP command confirms proper settings from the client.

Link to comment
Share on other sites

What happens if you try the "test" option in the client source screen with the IP of that client?

Robin, I don't think that there is a Client Test button in this released version; are you running 8.0.594.1? Maybe it's something we can look forward to getting back?

 

> I did trying browsing the hard drive from the sOUrces list, and it says "Source unavailable"

 

This confirms (as your Original Post suggested) that you had previously successfully added this Client. Were you previously able to back it up?

 

Have you Removed the (uncommunicative) client from the Sources list?

 

>If I go to add source, enter its IP address, type in the password, I get a green check next to

> the "Add" button.

 

 

Then what do you do?

 

Do you press the "Done" button in the "Enter the address of the source you want to add" drop-down sheet?

 

And then do you press the "Done" button in the multi-function drop-down sheet?

 

Is the client now listed in the Sources window?

 

Are you seeing other clients in the Multicast window?

 

If you click on the Sources from interface pop-up menu (mine says "Default;" does yours?), does your Multicast list of clients refresh?

 

Anything notable in the Network pane of the Retrospect preferences?

 

 

Dave

Link to comment
Share on other sites

This confirms (as your Original Post suggested) that you had previously successfully added this Client. Were you previously able to back it up?

Yes.

 

Have you Removed the (uncommunicative) client from the Sources list?

No. I don't want to have to rebuild the script.

 

Do you press the "Done" button in the "Enter the address of the source you want to add" drop-down sheet? And then do you press the "Done" button in the multi-function drop-down sheet? Is the client now listed in the Sources window?

Yes

 

Are you seeing other clients in the Multicast window?

No, but I didn't wait for it to scan.

 

As I am posting to this, I ran it again, and the multicast is not showing any clients.

 

 

If you click on the Sources from interface pop-up menu (mine says "Default;" does yours?), does your Multicast list of clients refresh?

Yes, it says "Default".

 

I didn't wait for it when I test earlier.

 

As I am posting this, no clients refresh in the multicast list.

 

Anything notable in the Network pane of the Retrospect preferences?

No - I haven't done anything there.

Edited by Guest
Link to comment
Share on other sites

I have an update to this for what it is worth, maybe you can look into it and get it in a bug fix update.

 

This has now happened to three of my sources.

 

They fail because the engine "can't find the client".

 

If I go into Sources to add a client, type in the failing client's IP address and password, click the "Add" button, the green check circle appears.

 

After that, the engine will see the client, and the script can be run.

 

Note that I am not actually adding the client in, it's already defined as a source; nor am I removing the old one and putting it back in. I am simply going to the add client box and going through motions of adding a new client - I just go to that first "green confirm check" indicator, then click done, it never is "added" to a list.

 

It is as if I am "tickling" the connection between the engine and the client, and that wakes it up or helps it find its path.

 

 

One thing to watch out for: I did this to a client that was listed in a script that was currently running (but it was backing up a different client at the time) and Retrospect (it appeared to be the engine) completely locked up.

 

I had to restart the physical server, which actually acted like a crashed/auto-recover server to get it running again.

Link to comment
Share on other sites

I'm having the exact same problem as you, and had hoped that your solution would work for me. Alas, it didn't. No matter what I try, the client isn't seen on the network. It used to be, but now for some magic reason, it isn't.

 

Sigh. Quite a disappointment.

 

BTW, only now I just noticed your gif's blinking eye. Heh, nice.

 

Link to comment
Share on other sites

Joel,

 

In an early post you said that the client was reinstalled as part of the troubleshooting. Did you forget and re-add the client after the reinstall?

 

When you did the reinstall, did you install on top of the client or did you uninstall and reinstall?

 

A uninstall/reinstall will require the client to be forgotten which you may not have done based on the post above.

 

This is logged as bug: 21826

Link to comment
Share on other sites

Joel,

 

In an early post you said that the client was reinstalled as part of the troubleshooting. Did you forget and re-add the client after the reinstall?

 

When you did the reinstall, did you install on top of the client or did you uninstall and reinstall?

 

A uninstall/reinstall will require the client to be forgotten which you may not have done based on the post above.

 

This is logged as bug: 21826

I ran the installer on top of the old install. But I think the install process was a red herring in regards to fixing or not fixing the issue.

 

Because since that early post I have had five other instances where other clients have lost their ability to communicate.

 

Doing the little dance of adding the client in, typing its Ip address and password, and getting the little green check box next to the "add" button is enough to reestablish the link.

 

Link to comment
Share on other sites

I'm getting this same behavior. Clients that were previously setup cannot be communicated with.

 

If I manually(enter IP) add them they start working again.

 

If I try to scan for new sources to add, using either "Use subnet broadcast" or "Use multicast" it returns NO clients now.

 

Just wanted to add to the reports...

Link to comment
Share on other sites

Another vote for resolving this. I am having the same issue: After a period of time (varies), server installations which have been previously functioning stop seeing any clients at all via multicast. Also, dependent scripts/viewing drive contents will consistently fail.

 

Adding the source via IP times out essentially... I've let this run for 2+ minutes per before losing patience.

 

This is on 2 separate installations of Retrospect 8.0.594.1, with mixed-environment clients, although predominantly Mac clients. Affects all scripts, proactive, timed, and manual executions. All software is up-to-date. One installation is 100% local and controlled for testing and exhibits these behaviors. Client software is responding in the client and ready to go, toggled on/off and restarted.

 

Furthermore, I am also experiencing the "I had to restart the physical server, which actually acted like a crashed/auto-recover server to get it running again" symptom on both systems running the new Retro engine.

 

Lastly, I'll add that my attempts to stop the Retro engine through the prefpane do not respond as soon as this happens. In an attempt to kill the process through Terminal, I can generate consistantly a recurring error in Console log indicating that "(com.retrospect.RetroEngine[41]) Did not die after sending SIGKILL xxx seconds ago." This will recur up until restart (hard restart, natch) of the offending Retro server machine, up to 167165 seconds on longest spin through.

 

Advice? Info on the next patch?

 

Regards,

 

Brendon Randall

Edited by Guest
Link to comment
Share on other sites

Interestingly, after updating to 8.0.608, I still can't see clients via multicast/subnet broadcast, but the "Add directly" command now updates them. Which doesn't work so well for DHCP clients, but is a move in the right direction for being able to see what else is working/not.

 

 

Link to comment
Share on other sites

If you run the engine on a different computer temporarily, can you see clients?

 

We have had users report that clients can not be seen in 8.0 via the broadcast. If the user does a re-install of the operating system, then clients magically appear with Retrospect running on the newly installed system. We don't yet know why this happens.

Link to comment
Share on other sites

Robin- yes to the last (running the engine on another machine can, at least initially, see the clients). I can also occasionally see them again after a number of restarts, but invariably, that ability goes away after a few hours. Given that, I trust that an OS reinstall would have almost identical effect, but I don't see that as a viable alternative given the inconsistency I have... if it just sorted it, that would be one thing; I suspect the problem will recur. If it's helpful, I can do so to one system this evening though.

Link to comment
Share on other sites

Robin-

 

Now I've blown those out (after the update) and it seems to be able to communicate again. Not confident that this will last, but the combination of the update->manual IP specification->blowing out prefs on the client seems to get the system into workable shape.

 

I now have one last issue on one test system using an older SCSI Ultrium 2 drive to archive from disk (instead of the Exabyte VXA Packetloader used on the first system). When I look in the "Storage Devices" section, I see the Certance Ultrium 2 DC device listed, with status "(wrong version)". The tape is sorta-kinda visible, listed only as "(Unknown)". Any activity that attempts to interact with the tape, or commands such as "Erase," try to run and just sit until Retrospect is force quit and the machine rebooted.

 

Thoughts on this? We can break this into another topic to be helpful to the rest of the community if need be.

 

Link to comment
Share on other sites

Wrong version mean the tape was probably written using 6.1. You should be able to erase this tape without the hang.

 

What type of SCSI card are you using?

What Mac OS version?

 

Do you see this hang if you try to erase a new already erased tape?

 

Does the OS X console give anything for this crash?

Link to comment
Share on other sites

Makes sense. I'm connecting to it using an ATTO UL5D card, and running OS 10.5.6 on a 2.8 quad-core Xeon Mac Pro, 4GB RAM, fresh install of OS and Retrospect 8. The other machine in question is same spec, 8GB RAM, same card, to a VXA PacketLoader 10, also running Quark Licensing Server in addition to Retrospect.

 

No console log entry on crash, just a quiet hang until force quit.

 

Also, need to restart the machine when troubleshooting, as the pref pane does not seem to work. If I click "Stop Server," I authenticate and get the following console entry:

 

4/10/09 10:52:21 AM [0x0-0x6b06b].com.apple.systempreferences[2059] 2009-04-10 10:52:21.924 Retrospect[2066:913] Retro Prefs Pane Helper: stop_server

 

But the pref pane does not update status, still shows running, and the Retro console can still see the running server. No amount of time seems to let it wrap up, and there were no running jobs. Lastly, restarting after Retro 8 install and updates still causes a shutdown hang, likely from some rogue process, however I can't see anything listed that looks bad after reboot. Real puzzler.

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...
×
×
  • Create New...