Jump to content
Sign in to follow this  
scotty321

Retrospect Client not being seen on Intel MacBook

Recommended Posts

Hi gang,

 

Are there any known issues with Retrospect Client 6.1.130 form working properly on Intel Macs, specifically the new Intel MacBook Core 2 Duo?

 

I have an entire office filled with Mac OS X machines running Mac OS X 10.4.8. Every machine is a PowerPC Mac, except for this new Intel MacBook Core 2 Duo. Every machine is being seen just fine, 100% of the time, by Retrospect -- EXCEPT for this MacBook. All the machines are awake & set to NOT sleep, but Retrospect on the server machine can NOT see the MacBook in the client list.

 

To try to fix this problem, I have uninstalled the Retrospect Client & reinstalled it again on the MacBook, and then -- lo and behold -- it can see the MacBook in the client list! smile.gif But, for some mysterious reason, a few hours later, it can no longer see the MacBook again. frown.gif I keep going through this process over & over again (uninstalling & reinstalling the Client again), and Retrospect can see it for a little while & then it loses it.

 

Sometimes when I try to configure the client, I get a never-ending "Net Retry" dialog box within Retrospect.

 

The MacBook is never asleep, and there are no firewalls in the way or anything unusual like that. All the other client machines on the network are being seen just fine.

 

And there doesn't appear to be anything wrong with the network. Everyone is plugged in using Ethernet cables (no wireless network at the office), and the MacBook is not having any other networking problems except with Retrospect. (The MacBook is constantly connected to the server for file sharing & for FileMaker Pro database access.)

 

Does anybody have any ideas on what could be going on here?

 

Thanks!

Scott

Share this post


Link to post
Share on other sites

People have been reporting that the Retrospect client keeps turning itself off on Intel Macs. Sounds like that is what you are seeing. The support people deny that this is happening, but there are multiple reports in these forums. It's not necessary to uninstall/reinstall to fix, only to turn the Retrospect client back on in its preferences. Unlike Retrospect, the Retrospect client isn't scriptable, so it's not possible to do a workaround hack such as a cron job that would turn the client on via AppleScript an hour before each scheduled backup.

 

As for the "Net Retry" thing, EMC/Insignia/Dantz keeps insisting with each release / update that this has been fixed, but it has not. I can make it happen if I shut down the client computer at just the right time, and that seems to be what is happening to you.

 

It's broken.

 

Russ

Share this post


Link to post
Share on other sites

Thanks, Russ, for the confirmation that this is really a genuine problem.

 

However, I am not having the EXACT same experience that you are where the Retrospect client turns itself off. If I launch the Retrospect Client, it actually says that it is ON and READY to go! Turning it off and on doesn't make the Retrospect server machine see it again either. On my end, the only way to solve this is the uninstall/install process.

 

BTW, for anyone who is wondering, we did NOT use the Migration Assistant on this MacBook Core 2 Duo -- every single application & every single preference on this entire machine was recreated from scratch when we bought this machine.

 

Thanks again!

 

Take care,

Scott

Share this post


Link to post
Share on other sites

> the Retrospect client isn't scriptable, so it's not possible to do a workaround hack such as a

> cron job that would turn the client on via AppleScript an hour before each scheduled backup.

 

Uh, sorry Russ, but where I come from that's what we call "crazy talk."

 

pitond is just a nice old (stress 'old') unix process. You can kill it from the shell. You can launch it from the shell. That means you can use cron to work that process, or use AppleScript to control Bash to control pitond.

 

> Turning it off and on doesn't make the Retrospect server machine see it again either

 

If by "turning it off and on" you mean clicking the "off" radio button on the Retrospect Client application (and getting a Status field message of "turned off") then you haven't actually stopped the pitond process.

 

To really kill the Retrospect OS X Client software, hold the Command key down while clicking on that "off" radio button. The Status field will read "Not running," and then when you click "on" again you'll have actually cycled the client software.

 

Dave

Share this post


Link to post
Share on other sites

Quote:

To really kill the Retrospect OS X Client software, hold the Command key down while clicking on that "off" radio button. The Status field will read "Not running," and then when you click "on" again you'll have actually cycled the client software.

 


 

Thanks, Dave -- I was not doing it that way. I will do it that way in the future and see if that immediately solves the problem for me. ALSO -- are you suggesting that perhaps the pitond process is somehow getting stuck or hanging on this MacBook? If so, do you have any suggestions to prevent the pitond process from hanging?

 

Thanks again,

Scott

Share this post


Link to post
Share on other sites

Sorry, but this problem is still not fixed. Robin Mayoff, is there anyone from your company working on this problem?!i My clients have collectively spent TENS OF THOUSANDS OF DOLLARS on Retrospect for their companies, and the Retrospect Client *DOES NOT WORK* on the Intel MacBooks. The Client continuously says "on", but Retrospect on the server can NOT see the client. We turn it off & turn it on again, and the server can see the MacBook for a little while, but very shortly thereafter, Retrospect can NOT see the MacBook again. Not sure if this is happening after the MacBook goes to sleep or if this is happening after the machine is restarted or what, but it happens EVERY SINGLE DAY WITHOUT FAIL. THIS IS A 100% REPRODUCIBLE PROBLEM, IN EVERY SINGLE ONE OF MY CLIENT'S OFFICES, AND EVERY SINGLE HUMAN BEING I DEAL WITH IS HAVING THIS EXACT SAME PROBLEM ACROSS THE BOARD. Are you guys doing ANYTHING to fix this problem? I put my neck on the line to recommend THIS BACKUP SOFTWARE, and it DOES NOT WORK.

Share this post


Link to post
Share on other sites

Also, LOTS OF PEOPLE are reporting this same problem on VersionTracker:

http://www.versiontracker.com/dyn/moreinfo/macosx/10479

What ever happened to this product which was once so good back in the early 90's? This product has gone sooooo downhill and the disappearance of most of the Macintosh support is so infuriating! This product used to be "Best of Class", and now it's struggling to even stay alive.

Share this post


Link to post
Share on other sites

Quote:

THIS IS A 100% REPRODUCIBLE PROBLEM

 


 

Yelling about it is not going to do anyone any good.

 

> Not sure if this is happening after the MacBook goes to sleep or if this is happening

> after the machine is restarted or what...

 

Not sure? Then what's the 100% thing about?

 

_Is_ the client on after the machine is restarted? Seems easy enough to test, and certainly would be something I'd test before yelling to the world.

 

_Is_ the client on after the machine wakes from sleep? Again, seems pretty darn easy to test, and seems like such a test would be the responsible thing to do before making claims of consistency.

 

(as posted on Version Tracker:)

> Please note that the Retrospect Client currently has a MAJOR BUG IN IT that PREVENTS it from

> working on Intel machines! It automatically stops running and the server can no longer see the

> Retrospect Client. This has been confirmed by many people on the Retrospect Forums...

 

Many people? Russ suggested that there are others, but I don't recall other threads besides this one. I'd certainly be interested in a link to other threads here with other users having a similar problem to yours.

 

> EVERY SINGLE HUMAN BEING I DEAL WITH IS HAVING THIS EXACT SAME PROBLEM

> ACROSS THE BOARD

 

Hmm. Well, I'm not. I'm backing up an Mac Mini Core Duo successfully using the 6.1.130 client. Of course, this being the internet and all, it's quite possible that I'm actually a dog, so I guess your above statement might still be valid.

 

There might very well be an issue with pitond on Core2 Duo machines. But what you've contributed to this thread makes it pretty much impossible to know (does "every single human being" you deal with use a Core 2 Duo MacBook Pro?). I've ramped up some stress activities on the Mini I back up, to see if the program looses connectivity.

 

But if you have a 100% reproducible issue, you should provide the specific steps it takes to reproduce it. Things such as what Type of backup set you using, what the status of pitond is when a machine disappears from the program list, how the machine was logged into the Client Database, the hardware of your Retrospect machine, the topography of your network, etc. Those are the sorts of details that are required for others to reproduce your problem, and thus move towards a solution, if one is possible. But EMC is putting very little into Retrospect currently; if there is a compatibility issue between the current release and the newest hardware from Apple (that every single human being you deal with uses) then there may be no solution coming.

 

 

Dave

Share this post


Link to post
Share on other sites

Quote:

Yelling about it is not going to do anyone any good.

 


 

Dave, thank you for being the voice of reason, but if EMC is no longer putting any more effort into Retrospect, how can we get this fixed without yelling about it??

 

Quote:

_Is_ the client on after the machine is restarted? Seems easy enough to test, and certainly would be something I'd test before yelling to the world.

 

_Is_ the client on after the machine wakes from sleep? Again, seems pretty darn easy to test, and seems like such a test would be the responsible thing to do before making claims of consistency.

 


 

Okay, I will test these things in more detail, but as far as I can tell, it seems to happen after the machine goes to sleep. Retrospect Client ALWAYS says that it's on, but Retrospect on the server machine doesn't see it. Holding down the command-key while clicking on the "Off" button in Retrospect Client, and then holding down the command-key while clicking on the "On" button seems to wake it up again, I believe.

 

Someone on VersionTracker discovered a workaround that involves disabling ACL's from within Terminal. I just tried this today to see if this solves the problem.

 

Quote:

Hmm. Well, I'm not. I'm backing up an Mac Mini Core Duo successfully using the 6.1.130 client. Of course, this being the internet and all, it's quite possible that I'm actually a dog, so I guess your above statement might still be valid.

 


 

Actually, I'm glad you brought this up. You are absolutely right -- this issue is isolated to Core 2 Duo machines! It has happened to all of my clients who are running Core 2 Duos, but it is NOT happening to my clients who are running Core Duos. Thank you for enabling me to pinpoint this problem.

 

Quote:

But if you have a 100% reproducible issue, you should provide the specific steps it takes to reproduce it. Things such as what Type of backup set you using, what the status of pitond is when a machine disappears from the program list, how the machine was logged into the Client Database, the hardware of your Retrospect machine, the topography of your network, etc. Those are the sorts of details that are required for others to reproduce your problem, and thus move towards a solution, if one is possible.

 


 

Okay, I will put together this information so that this can REALY be reproduced 100% successfully by anyone who wants to try it themselves!

 

Quote:

But EMC is putting very little into Retrospect currently; if there is a compatibility issue between the current release and the newest hardware from Apple (that every single human being you deal with uses) then there may be no solution coming.

 


 

It is very disheartening to hear this news, and I assume that this means that all Retrospect development for Macintosh has stopped. This is a real shame, especially after all of my clients have invested their money in this product.

 

In the meantime, I will put together a list of criteria that will faithfully reproduce this problem every single time.

 

Thanks,

Scott

Share this post


Link to post
Share on other sites

> Someone on VersionTracker discovered a workaround that involves...

 

No, the issue regarding ACLs on Intel macs was not discovered/revealed on Version Tracker. This is a know issue, for which there is a new build of the program.

 

But if you're not running OS X Server, you don't have ACL's enabled unless you went out of your way to enable them. And if you _are_ running OS X Server, you neglected to include that _very_ important fact in any of your posts.

 

> I assume that this means that all Retrospect development for Macintosh has stopped...

 

You know what it means when you assume...

 

As far as has been revealed publicaly, "all Retrospect development for Macintosh" has not stopped. But it's quite apparent that the development resources today are less then they might have been a few years ago.

Share this post


Link to post
Share on other sites

Quote:

Russ suggested that there are others, but I don't recall other threads besides this one.

 


Yes, I've seen this reported a few times. But the posters never report back on the resolution, so I can't say it's a "confirmed issue" like we seem to have here, with someone who seems motivated to perhaps help track the issue down. It's been unclear in the past whether it was this issue or whether it was another issue caused by moving/renaming the Retrospect Client so that pitond didn't get started on reboot. But Scott seems to be on to something here, and has isolated it to a hardware configuration on which it can be tested. useful.

 

Quote:

Retrospect Client ALWAYS says that it's on, but Retrospect on the server machine doesn't see it. Holding down the command-key while clicking on the "Off" button in Retrospect Client, and then holding down the command-key while clicking on the "On" button seems to wake it up again, I believe.

 


Ok. There are a few commands that might provide information (although, Scott, you seem to have isolated this well enough that a decent programmer at EMC should be able to take it from here with your reproducible hardware configuration). When the client gets into this mode (after the Core 2 Duo wakes up from sleep) and before you do the command-On trick (if, in fact, that makes the client show up in Retrospect):

(1) can you ping the client from the Retrospect server machine? (will show whether the network interface is active)

(2) What is the output of the following commands:

Code:


netstat -p udp

netstat -ia

ps axl | grep pitond


Then, after you do the command-On trick (if that gets Retrospect to see the client), repeat the previous stuff.

 

This might show what the process state difference is for pitond, what stuff is open on the network, and also what the state of the udp4 *.dantz stuff (port 497) is. But, candidly, I'm not sure how much use this is. Scott seems to have carried this as far as a user can, and it really seems to need a programmer with the code in hand on the indicated configuration to go further. Seems like a pretty easy test for EMC support to set up.

 

Quote:

But it's quite apparent that the development resources today are less then they might have been a few years ago.

 


Yea, I'm discouraged, too. I've worked at startups that have gone under, and I've seen the pattern.

 

Russ

Share this post


Link to post
Share on other sites

Quote:

But if you're not running OS X Server, you don't have ACL's enabled unless you went out of your way to enable them. And if you _are_ running OS X Server, you neglected to include that _very_ important fact in any of your posts.

 


 

No, not running Mac OS X Server. Just running Mac OS X 10.4.8 on this MacBook Pro Core 2 Duo. I don't know what ACL's are, so they're clearly not enabled.

 

Same problem today and every day -- is EMC even looking into this problem? I honestly have absolutely no idea what their engineers do all day long if they can't fix tis problem! I'm not sure if the problem kicks in after waking up the MacBook Pro from sleep or after one successful backup.

 

See my next posting for some more information.

Share this post


Link to post
Share on other sites

Quote:

(1) can you ping the client from the Retrospect server machine? (will show whether the network interface is active)

 


 

Thanks so much for your help -- you are doing more than EMC themselves are doing for my problem!

 

Yes, I can successfully ping the client from the Retrospect server machine.

 

Quote:

(2) What is the output of the following commands:

Code:

netstat -p udp

netstat -ia

ps axl | grep pitond

 


 

Can you please give me a hint as to what I should be looking for? The first 2 lines return a BUNCH of information, but when I type in the 3rd line, nothing is returned.

 

Quote:

Then, after you do the command-On trick (if that gets Retrospect to see the client), repeat the previous stuff.

 


 

The command-on trick does indeed get Retrospect to see the client again. But the 3rd line of code above still returns nothing in the Terminal.

 

Thanks again, Russ, for your help.

 

You know what I really wish? That EMC would actually post some sort of a reply about this, or that Robin Mayoff & his crew would actually show some sort of concern for their Mac users which they have abandoned. Obviously, this is a serious problem that is affecting others as well -- and Dantz is completely silent on the issue. They've basically stolen money from us as far as I'm concerned, because the product is not working as advertised and they are not responsive to technical support requests.

 

Thanks,

Scott

Share this post


Link to post
Share on other sites

Scott,

 

This is not, and never has been, a forum for communication with EMC support. This is a user-to-user support forum. If you have any expectations that it is anything more, you are mistaken. Read the "Welcome to the Forum" description of this forum:

Welcome to the Forum

 

Quote:

They've basically stolen money from us as far as I'm concerned, because the product is not working as advertised and they are not responsive to technical support requests.

 


Have you contacted support and turned in a support request? I don't see any evidence in your posts that you have. You just seem to want to rant, and I have no interest in participating in that.

Contact Support

 

Russ

Share this post


Link to post
Share on other sites

Thanks. I don't really want to rant, I just want them to address the problem. I have not turned in a support request. I was under the impression that it would cost us money to even report this as a bug. I can't find anything that differs from that impression on the link that you sent above. Doesn't EMC give some free support requests after a purchase? We just bought this for this client a few months ago. The fact of the matter is that this is most certainly a bug... all 9 other non-Intel Macs on the network are working just fine. It was only the introduction of a brand new Intel Core 2 Duo MacBook when the problems started arising. (No Migration Assistant, just a brand new machine right out of the box.)

 

Thanks,

Scott

Share this post


Link to post
Share on other sites

Quote:

Doesn't EMC give some free support requests after a purchase?

 


Yes, there are 30 days free support. After that, you either purchase per-incident support or, as we have done, you purchase an annual maintenance contract. Just like we do on our Xserve. Just like we do on our SonicWALL firewall. Just like ..... Software support costs money. For us, our data is valuable, so we purchase support for the hardware and software that protects it.

 

The benefit of the Retrospect annual maintenance contract is that you get free upgrades to newly released versions, if that ever happens.

 

Now that we are over that, let's focus on the three commands. Make sure you have your terminal window set wide or that may be the reason you are not getting any output from the ps axl command. If you have the window set wide, and you still don't get output, it shows that the client daemon is not running.

 

Here is sample output (i've deleted the lines that aren't important):

Code:


rhwimac:~ rhwalker$ netstat -p udp

Active Internet connections

Proto Recv-Q Send-Q Local Address Foreign Address (state)

udp4 0 0 *.dantz *.*

rhwimac:~ rhwalker$ netstat -ia

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

en0 1500 <Link#4> 00:03:93:b3:2e:9e 6254981 0 12114670 0 0

1:0:5e:1:0:26

1:0:5e:7f:ff:fd

1:0:5e:0:0:fb

1:0:5e:0:0:1

9:0:7:ff:ff:ff

en0 1500 (16)00:00:ff:8d:81 6254981 0 12114670 0 0

en0 1500 192.168.0 rhwimac.walkerm 6254981 - 12114670 - -

224.1.0.38

239.255.255.253

224.0.0.251

all-systems.mcast.net

rhwimac:~ rhwalker$ ps axl | grep pitond

UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND (this line added for clarity)

0 193 1 0 31 0 30844 1132 - S ?? 30:26.92 /Applications/Retrospect Client.app/Contents/Resources/pitond

501 6493 6459 0 31 0 18048 248 - R+ p1 0:00.01 grep pitond


The first command shows that the client is listening on the dantz port (port 497). If, for example, you telnet to your machine's IP and port 497, you will see additional lines for that connection (I wanted to see if something else had your port connected, perhaps some other retrospect, and whether the port was open). The second command shows that the ethernet interface is up and accepting multicast, and that we aren't seeing collisions or errors. The third command shows that the pitond (retrospect client) process is running, and that its UID is 0 (root).

 

If you feel that your money has been stolen, contact your state's attorney general and/or the Better Business Bureau.

 

Russ

Share this post


Link to post
Share on other sites

> I have not turned in a support request. I was under the impression that it would cost us

> money to even report this as a bug.

 

It will cost you money to open up a dialog with a human technical support person at EMC. If this is an actual software defect (bug) you can request, and will likely receive, a refund. Of course, there's always the chance that it's not a bug (given the fact that the client works reliably on other Core2Duo MacBooks and MacBook Pros out there), and that perhaps your conversation might result in the software working successfully for you.

 

> Doesn't EMC give some free support requests after a purchase?

 

Yes.

 

Although I must confess to be confused as to why, that given the fact that you believe you are entitled to free support, you didn't call them a month ago.

 

> The fact of the matter is that this is most certainly a bug

 

Facts? Who needs facts? You feel this in you GUT! It simply _must_ be a bug!

 

> The command-on trick does indeed get Retrospect to see the client again

 

Just to be clear, Command+On-radio-button is not a special key combination in the Retrospect Client application.

 

The special key-press is Command+Off

 

If you have a key routine that makes a difference, please describe it for us, including the text shown in the Status field both before and after you click on things.

 

And while I'm asking for a clearer description of the problem, note that there are two places where clients are listed ("client list" from your initial post) in Retrospect. There is the Client Database window, and there is the Backup Clients on Network window, with a list of clients that respond to Retrospect's broadcast discovery. Where, exactly, are you seeing or not seeing the client?

 

> I honestly have absolutely no idea what their engineers do all day long if they can't fix tis problem!

 

The engineers at EMC do not know that you are alive, and they do not know that you are having this problem. Now, if you actually call them, and tell them, they'll be more likely to try and work with you to help.

Share this post


Link to post
Share on other sites

Scotty321,

 

Do you have any non-Intel Mac laptops running the Retrospect client in your environment? Because I have seen LOTS of problems with Retrospect server being unable to locate clients for a wide variety of reasons, with a slew of workarounds.

 

Our biggest problems have very little to do with Intel, and lots to do with configuration issues related to portables. For example, in our heavily VLAN'ed large network environment, DHCP confuses our Retrospect server to no end. Also, I have seen battles on clients between Airport and Built-In Ethernet which render Retrospect unable to communicate properly with them.

 

Finally, 10.4.9 was just released, and it purports to resolve specific network problems with Intel iMacs (such as duplexing). Since we have also been seeing identical networking problems with MacBooks, we plan to test this OS update and hope to the higher power that it addresses what we are seeing.

 

Let us know if you learn anything more. Good luck!

Share this post


Link to post
Share on other sites

Quote:

I have seen LOTS of problems with Retrospect server being unable to locate clients for a wide variety of reasons, with a slew of workarounds

 


 

Please be careful not to confuse the issues here. There is a very great difference between a machine running the Retrospect application being unable to locate a valid client machine, and a machine that exhibits issues related to successfully running the client software.

 

Of _course_ Retrospect won't be able to locate a machine that's not running the client software!

 

At this point in the thread, there has not yet been confirmation regarding that state of the client software on the machine in question. Knowing if pitond is running, and knowing if pitond starts at system-start, and knowing if piton stays up after a sleep/wake cycle are still outstanding questions that have not yet been addressed.

 

Dave

Share this post


Link to post
Share on other sites

Actually, I find that this problem happens not on Intel machines, but that after reboot on 3 of our PowerPC machines (an eMac G4, a dual G5 PowerMac, and a PowerMac G4). It works fine on all of our Intel and other PPC machines.

 

The symptom is 100% reproducible. Restart any of these 3 after confirming that Retrospect Client is on ... and Retrospect Client will be off. All of these machines used to work fine. Since I didn't see it when it happened, I suspect that the problem crept in with one of the 10.4.x software updates. These machines are all on 10.4.8.

 

I've experimented with the ACL solution posted on VersionTracker, and it makes no difference.

 

Any ideas that anyone has, would be appreciated.

 

Neil

Share this post


Link to post
Share on other sites

Quote:

The symptom is 100% reproducible. Restart any of these 3 after confirming that Retrospect Client is on ... and Retrospect Client will be off. All of these machines used to work fine.

 


 

Likely one of two things:

 

- You moved the location of the Retrospect Client.app from its default installed location in /Applications/

 

or

 

- You moved or removed the shell script:

/Library/StartupItems/RetroRun/RetroRun

 

Of course, that's not "this problem" at all...

 

Dave

Share this post


Link to post
Share on other sites

Quote:

Actually, I find that this problem happens not on Intel machines, but that after reboot on 3 of our PowerPC machines (an eMac G4, a dual G5 PowerMac, and a PowerMac G4). It works fine on all of our Intel and other PPC machines.

 

The symptom is 100% reproducible. Restart any of these 3 after confirming that Retrospect Client is on ... and Retrospect Client will be off.

 


If the poster is the real Neil Ticktin, Publisher of MacTech Magazine, I am honored to be able to respond. Read your fine magazine every month. But, of course, this is the internet, and you could be a dog.

On the Internet ...

 

If you are really Neil Ticktin, then you already know all of this stuff that I am about to say, and you certainly know much more than I ever will about Mac internals.

 

The ACL hack doesn't matter on PPC. It sounds like you have a different problem than the one Scott has been troubleshooting.

 

Is it possible that your client has been moved or renamed on these machines so that the StartupItems on reboot doesn't start the client? Easiest way to fix (if the Startup Item is the problem), would be to uninstall and reinstall the client.

 

You don't say what version client you have. I would hope that you've got Retrospect Client 6.1.130. If not, the link is here for the Read Me file:

Retrospect Client Read Me

and is here for the disk image file itself:

Retrospect Client 6.1.130

 

Here's how the startup is supposed to work:

/Library/StartupItems/RetroClient holds two items:

 

Code:


rhwimac:/Library/StartupItems/RetroClient rhwalker$ ls -l

total 32

-rwxr-xr-x 1 root wheel 349 Oct 29 2003 RetroClient

-rwxr-xr-x 1 root wheel 208 Oct 29 2003 StartupParameters.plist


These cause the RetroClient shell script to run and, if the client is to start up (if the file /Library/Preferences/retroclient.state exists), to launch the Retrospect client (pitond) buried within the Retrospect Client application:

/Applications/Retrospect\ Client.app/Contents/Resources/pitond

 

A log message is also put in the Console Log that says "Starting Retrospect Client". Does this message appear in your console log during the boot process? If not, then either the retroclient.state file didn't exist (the client wasn't supposed to start; perhaps permissions prohibited that file from being created by the Client when turned on?) or the pitond program couldn't be found. An uninstall/reinstall would fix.

 

Your problem may have been inadvertently caused by you in the distant past when trying to fix a different security hole. At one time in the far distant past, some permissions were set wrong on the Retrospect Client (and within the directory structure that is hidden as the .app). Because Retrospect client (pitond) runs setuid, it's pretty important that other programs (malware) not be able to overwrite it because they would get setuid privileges when pitond is started during boot. At one time there were some postings in forums about this security hole, and some people went blindly changing permissions, that might prevent Retrospect's client from writing/changing its retroclient.state file, which could prevent startup. I believe that the installer has since been fixed so this issue isn't a concern any more.

 

The installer can also uninstall, and that would ensure that the startup procedure is correct, and would get us at a known starting point. Just change the drop-down selector from "Easy Install" to "Uninstall".

 

The uninstall/install sequence should fix that, if that is your problem.

 

It might be instructive to see whether retroclient.state exists just before your reboot after turning the client on. Here's how it should look:

 

Code:


rhwimac:/Library/Preferences rhwalker$ ls -l /Library/Preferences/retroclient.state

-rw-r--r-- 1 root admin 2136 Mar 15 19:33 /Library/Preferences/retroclient.state


Could you try uninstalling and then reinstalling the client?

 

russ

Share this post


Link to post
Share on other sites

Quote:

Scotty321,

 

Do you have any non-Intel Mac laptops running the Retrospect client in your environment? Because I have seen LOTS of problems with Retrospect server being unable to locate clients for a wide variety of reasons, with a slew of workarounds.

 

Our biggest problems have very little to do with Intel, and lots to do with configuration issues related to portables. For example, in our heavily VLAN'ed large network environment, DHCP confuses our Retrospect server to no end. Also, I have seen battles on clients between Airport and Built-In Ethernet which render Retrospect unable to communicate properly with them.

 

Finally, 10.4.9 was just released, and it purports to resolve specific network problems with Intel iMacs (such as duplexing). Since we have also been seeing identical networking problems with MacBooks, we plan to test this OS update and hope to the higher power that it addresses what we are seeing.

 

Let us know if you learn anything more. Good luck!

 


 

Thanks for your feedback. Yes, we have 5 non-Intel Mac laptops running the Retrospect client in this office without any problems, and every single laptop has been assigned a manual IP address. All the laptops (both Intel & non-Intel) switch between Ethernet at the office and Airport at home, and they are always using their manual IP address unless they are surfing the web somewhere else such as a hotel. But 95% of the time, they are using their manual IP address.

 

You know what's so crazy is that Retrospect is becoming less & less important due to more capable & much more inexpensive programs such as the excellent $30 ChronoSync (or programs like SuperDuper). My temporary workaround for this disaster is that I installed ChronoSync on the laptop and I am having ChronoSync "push" the home folder from the laptop to the server on a daily basis, and I have turned OFF Retrospect Client instead.

 

And here's where things have gotten interesting: Once I turned OFF the Retrospect Client altogether on this Intel MacBook Core 2 Duo by me, the Retrospect Server has CONTINUOUSLY seen this client machine as "Not Logged In" on a daily basis. Even through restarts & waking up from sleep & switching from Airport to Ethernet, the Retrospect Server has now always seen this client machine, now that the client is always turned off. So I'm wondering if maybe the problem of Retrospect Server not seeing the Client occurs AFTER a successful Retrospect backup of that client?

 

I'll have to do some more research on this issue to see if I can pinpoint this further.

 

Thanks,

Scott

Share this post


Link to post
Share on other sites

Quote:

Although I must confess to be confused as to why, that given the fact that you believe you are entitled to free support, you didn't call them a month ago.

 


 

Because we bought the software 4 months ago, and the problem didn't crop up until a month ago when the new Core 2 Duo laptop was purchased. So we no longer have free technical support from them. A $30 investment in ChronoSync was a much better investment in solving this problem, and enables us to make the long-term goal of leaving Retrospect behind altogether since they are clearly dropping their Mac support.

 

Quote:

And while I'm asking for a clearer description of the problem, note that there are two places where clients are listed ("client list" from your initial post) in Retrospect. There is the Client Database window, and there is the Backup Clients on Network window, with a list of clients that respond to Retrospect's broadcast discovery. Where, exactly, are you seeing or not seeing the client?

 


 

Right, it's the "Backup Clients on Network" window, where the client is no longer responding to Retrospect's broadcast discovery. It doesn't show up there at all, but all the other laptops do. In the other window, the "Client Database" window, it shows up greyed out.

 

Thanks,

Scott

Share this post


Link to post
Share on other sites

Quote:

Now that we are over that, let's focus on the three commands.

 


 

Quote:

Make sure you have your terminal window set wide or that may be the reason you are not getting any output from the ps axl command. If you have the window set wide, and you still don't get output, it shows that the client daemon is not running.

The first command shows that the client is listening on the dantz port (port 497). If, for example, you telnet to your machine's IP and port 497, you will see additional lines for that connection (I wanted to see if something else had your port connected, perhaps some other retrospect, and whether the port was open). The second command shows that the ethernet interface is up and accepting multicast, and that we aren't seeing collisions or errors. The third command shows that the pitond (retrospect client) process is running, and that its UID is 0 (root).

 


 

Wow, thanks Russ for posting all of this for me. I'm still not quite sure this makes sense to me, but I will run this and let you know what I find out.

 

Thanks,

Scott

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  

×