Retrospect Client Turns itself off

[fredturner]

Quote:

---

One would expect the administrator of an XServe to have a grasp on the basics of critical software components, such as that which is responsible for the data protection of over a dozen users.

 

---

 

Wow. How obnoxious. Dave, are you able to respond to _any_ posts without condescending? I don't even frequent this board, yet I've seen enough of your attitude in this thread alone to know that you'd be a lot more helpful if you would stop p*ssing off everyone by talking down to them. Try dropping the attitude for a post or two. We'd all appreciate it. Or just don't post.

 

 

Now, to add my experiences, this is most definitely a software glitch and a serious problem. I've seen it occur at several different customers' sites, even after doing the non-specific (and usually non-helpful) uninstall/reinstall dance. I did not really notice it until version 6.1.130 of the client software. I find it surprising that EMC Insignia has that KB article from at least as early as 11/06, yet no update has been put out to address this. It's pretty easy to replicate. Just install the "latest software" (yes, Dave, client 6.1.130 and Retro 6.1.126) on a server and a few clients, wait a few days, and you'll have clients w/ the Retrospect Client radio button set to "Off"...all by themselves.

[sniles]

Dave - thanks for piping in; here are clarifications to my sub-standard descriptions:

 

Quote: I'm not sure exactly what "the configuration dialog active" means.

 

I meant that I had gone to Configure Clients and selected the problem client and gotten to the Client Configuration window.

 

Quote: But, in general, Retrospect can still open the Client Configuration window for a client that is not currently visible.

 

I know.

 

Quote: It will open to the "General" tab, but the only way to know for sure if the program can communicate with the Client is to click on one of the other tabs, either Configure or Volumes....

 

I know.

 

> Sometimes this is fixed by restarting the errant client, but lately that doesn't work either.

 

Does this mean restarting the errant client computer? Or restarting the errant client software?

 

The errant client's computer.

 

Thanks for your other thoughts. I will be investigating the "Sleep" mode thing first, per both Russ and you. I think that may be on the money - and a very easy fix!

 

Bigger problem right now is, today I arrived to find my main storage drive on the server went bye-bye. Been working off its backup twin drive, letting Retrospect finish its work from last night that got stopped by the drive crash, and will troubleshoot the whole mess tomorrow. Also getting a quote on a new server! We have been having a lot of trouble with it.

 

Thanks for your help, guys. I'll be back...

~S

 

PS, Dave - I am responsible for the computer systems and backups for my department, but it is not the biggest part of my job, and I have zero formal training in these topics. I know enough to get by usually, but am quite ignorant regarding the Server software, finer points of networking, and backups as well as my own graphics work and the company's intellectual property issues. Believe it or not, I am the least ignorant here - in a small company with tight knots, velcro, zippers and rivets on the purse strings. I wonder if the person you thought was too unknowledgable about X-Serve for his 12 clients is maybe in the same boat?

[sniles]

Whoops! Ignorant about servers, networks and backups - NOT ignorant about graphics and IP!

[rhwalker]

Quote:

---

Now, to add my experiences, this is most definitely a software glitch and a serious problem. I've seen it occur at several different customers' sites, even after doing the non-specific (and usually non-helpful) uninstall/reinstall dance. I did not really notice it until version 6.1.130 of the client software. I find it surprising that EMC Insignia has that KB article from at least as early as 11/06, yet no update has been put out to address this. It's pretty easy to replicate. Just install the "latest software" (yes, Dave, client 6.1.130 and Retro 6.1.126) on a server and a few clients, wait a few days, and you'll have clients w/ the Retrospect Client radio button set to "Off"...all by themselves.

 

---

Fred,

 

This is why I responded as I did to Sandy's (sniles') information by saying:

Quote:

---

With PPC computers, we should be able to figure it out.

 

---

There are some people who have reported problems with 6.1.130 on Intel clients, and I don't think it's ever been resolved there. It's my suspicion that the Intel Macs don't wake up the same as PPC Macs. As an added twist, Mac OS 10.4.x Universal Binary (server and non-server) is a very different animal (not simply a strict equivalent UB of the PPC code) than Mac OS 10.4.x PPC. It has caused fits for some of us with servers. So the problem may be with the Intel hardware or it may be with the Universal Binary code. But I believe that this problem has always been solvable on PPC Macs. That's why I tossed out the experiments that I did, to see which solution path needed to be followed here.

 

Just out of curiosity, Fred, what hardware do you have on your clients that become deaf?

 

Russ

[CallMeDave]

Fredturner writes:

 

>Dave, are you able to respond to _any_ posts without condescending?

 

Yes. I belive my very first reply to the original poster on this thread was quite civil. Sadly, the original poster never posted again. So the questions I asked, regarding exactly how his problem manifested itself, were never answered.

 

I also think my second post in this thread, replying to the very unhelpful "I have the same problem" post, was a reasonable reaction to a frustrating phenomena. This isn't a Curb Your Enthusiasm discussion board; data protection is pretty serious business.

 

My third post to this thread was also quite reasonable, and should have been helpful, consisting just of a direct link to a relevant Knowledge Base articla and a snippit of text (good netiquette to provide some context in advance of the user deciding if clicking on the link is warranted).

 

My fourth post to this thread was utterly devoid of snark. I simply quoted the three questions and provided the three answers. I then asked two additional questions in the hope of providing additional answers.

 

My fifth post to this thread was more question then answer, but since those questions weren't answered by the poster, they needed to be asked.

 

But it was my sixth post to this thread that positively dripped with snark. And I stand by it. OS X Server is not a toy. It's not just a modern version of AppleShare IP. Programs such as BIND can wonk a local network if not configured properly, or even effect users on remote networks if the machine has a routable address.

 

I felt that someone responsible for administering OS X Server should have the ability to read an entire thread (pitond was referenced 9 times in advance of my question) and provide answers to questions posed by two different participants.

 

 

I've seen it occur at several different customers' sites

 

Have you seen "it occur" on both PPC and Intel machines?

 

 

> Just install the "latest software" ... and Retro 6.1.126) on a server

>and a few clients, wait a few days, and you'll have clients w/ the

>Retrospect Client radio button set to "Off"...all by themselves.

 

And there's the rub. Because not everybody does. I have half a dozen clients running, backed up daily, and never, not once, have I seen what you describe above (a description lacking, I must add, a report regarding the text displayed in the Status field of the Retrospect client application, even though it has been asked three times already in this thread, once in all caps!).

 

 

I don't doubt that people are experiencing unexpected behavior. But without providing thorough configuration information and specific observational data, it's unlikely that a common cause will reveal itself.

 

Oh, and I do appreciate your concern for the delicate sensibilities of the users who come to this forum looking for answers. I suppose I could tone down my "attitude," or even just stop posting, as you suggest. But since most all the responses provided on this section of the Forum are handled by only three community members, who'll pick up the slack? You, fredturner?

[rhwalker]

Quote:

---

> Just install the "latest software" ... and Retro 6.1.126) on a server

>and a few clients, wait a few days, and you'll have clients w/ the

>Retrospect Client radio button set to "Off"...all by themselves.

 

And there's the rub. Because not everybody does. I have half a dozen clients running, backed up daily, and never, not once, have I seen what you describe above

 

---

As one who has been accused of condescension and attitude in the past, I'll have to agree with Dave.

 

I have been running Retrospect since 1992 on our network and its clients on all of our computers since then. Back then it was ASIP and what is now called Mac OS Classic. Now it is Mac OS 10.4 (server and non-server) on our current mix of computers. We have never seen this "Retrospect Client Turns itself off" issue. Never. But I'm not saying that the problem doesn't or can't exist, nor is Dave.

 

Each of us contributes something different to these forums. My background, before I became a patent attorney, was designing computers and OS software (including a 4.2BSD Unix port, a number of unix drivers, and unix OS internals software), and I've got bachelor's and master's degrees in EECS from MIT. Our backup is only to tape, so my assistance is usually limited to tape/autoloader stuff, networking stuff, and OS-type stuff.

 

Of all the users who assist other users in these forums, Dave is, in my opinion, by far the most knowledgeable on the operation of Retrospect and its quirks. Certainly more knowledgeable than I am. You would do well to listen to what he says and to answer his questions with the care that he asks them. If you don't, you will be frustrated and you won't get your problem solved. We try to get the information we need to help you solve your problems. That's the way this forum works. And sometimes it gets frustrating trying to get even the simplest necessary morsels of information from posters. Remember, we don't get paid for helping you.

 

Look - Retrospect is not a perfect product. No product is. Those of us users who regularly post in these forums are trying to help the community limp along on the product so that, hopefully, EMC can have time to fix the long-standing bugs and update the product. It has promise that we all hope will be realized.

 

Russ

[fredturner]

Quote:

---

Of all the users who assist other users in these forums, Dave is, in my opinion, by far the most knowledgeable on the operation of Retrospect and its quirks. Certainly more knowledgeable than I am. You would do well to listen to what he says and to answer his questions with the care that he asks them. If you don't, you will be frustrated and you won't get your problem solved. We try to get the information we need to help you solve your problems. That's the way this forum works. And sometimes it gets frustrating trying to get even the simplest necessary morsels of information from posters.

 

---

 

I understand that, certainly. Most of my clients are notoriously poor in giving me the information I need to solve their problems, so I understand where you're coming from. But don't start saying stuff like (paraphrasing): "If you're supporting a dozen users, you're a moron for not knowing Unix." Number 1...CONDESCENDING; #2, it's not an absolute-- the whole point of Mac OS X Server is to have a system that someone without a deep Unix or server background can set it up. Do you benefit from knowing more about the guts of the system? Absolutely. But there's no need to act like that.

 

Now, I didn't go into enormous detail about the problem I'm experiencing, because I believe it to be a fault of the current version (yes, 6.1.130) of client software-- hell, the KB article (from LAST FREAKIN' FALL!) acknowledges there's a problem, although I disagree that it only affects AirPort-connected clients. Anyway, IMO, there's not much we can do until EMC resumes paying the power bill in the Mac Retrospect development office... I simply wanted to mention that here's yet another case (well, several, as I have several customers affected by this) of the problem. Variety of systems, variety of "switched off" Retro Clients. Simple as that.

[rhwalker]

Quote:

---

... I disagree that it only affects AirPort-connected clients. ... Variety of systems, variety of "switched off" Retro Clients.

 

---

Fred,

 

Are you saying that you are seeing this on wired PPC clients running Retrospect Client 6.1.130 in which the client has not been moved from its installed position in the Applications folder? I don't believe we have seen a confirmed case, with details, of that before. I think that all cases with such a configuration have been able to be resolved.

 

Russ

[rmcken]

>Are you saying that you are seeing this on wired PPC clients running Retrospect Client 6.1.130 in which the client has not been moved from its installed position in the Applications folder? I don't believe we have seen a confirmed case, with details, of that before. I think that all cases with such a configuration have been able to be

resolved.

 

That gives me hope. I have a G5 iMac with this issue. I have cobbled together what I hope is the definitive list of Requests for Information from several posters of this thread.

 

(1) current one is Retrospect Client 6.1.130...

 

I have that client installed on a G5 iMac OSX 10.4.10, the client 'turns off' at seeming random intervals.

 

(2) locate pitond

 

motley$ locate pitond

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

 

(3) Between these times when the Client is on and later seems to turn off, has there been a restart or reboot of the client computer? Has the client computer gone to sleep? Is this a "wired" or "wireless" connection from the client computer to the Retrospect machine?

 

Not wireless, possible restarts or shutdowns but they don't seem to relate to the issue. The restarts that I do always come up with the client on and getting backed up. It is set to sleep after 3 hours, but I don't think that is the issue. This client is setup as a proactive client on the server and should get backed up sometime when the user is on and working (several hours/day).

 

(4) ps axlwww | fgrep pitond

 

motley$ ps axlwww | fgrep pitond

501 5707 3907 0 31 0 27812 4 - R+ p1 0:00.00 fgrep pitond

 

There is no second line, pitond is not running.

 

(5) ls -ald /Library/StartupItems/Retro*

 

motley$ ls -ald /Library/StartupItems/Retro*

drwxr-xr-x 3 root wheel 102 Aug 2 2006 /Library/StartupItems/RetroClient

 

(6) cat /Library/StartupItems/Retro*

 

This command fails. There is only one file in the /Library/StartupItems/RetroClient folder:

 

$ cat StartupParameters.plist

{

Description = "RetroClient daemon";

Provides = ("Network Backup");

OrderPreference = "Late";

Messages =

{

start = "Starting RetroClient";

stop = "Stopping RetroClient";

};

}

 

 

>and have eliminated the various possibilities suggested in those threads? Have you seen this KnowledgeBase article

and followed the steps there: Retrospect Client turns itself off on restart

 

I've clean reinstalled a few times, it seems to always come back eventually. Oh, and the retro client, when off, reports "Status Not Running" under Status and nothing under history (is that what CallMeDave needs?).

 

>>Is there a way to run pitond remotely (via ssh), or with a cron job? Is that the only daemon that needs to be run?

>Yes, yes and yes. You can use sudo and run pitond the same way you would run any unix process; it lives in /Applications/Retrospect\ Client.app/Contents/Resources/pitond

 

 

What exactly would I need to run in a cron job? Just launch the program- no switches, no problem if it's already running? I'd like to try this and see if that solves the issue.

 

> Is there anything in /Library/Logs/CrashReporter/ ?

 

There is no /Library/Logs/CrashReporter under console on this box, but there is ~/Library/Logs/CrashReporter which shows nothing for retrospect. Thanks.

 

ross

[CallMeDave]

Quote:

---

There is only one file in the /Library/StartupItems/RetroClient folder:

 

---

 

Well, that would be a problem.

 

The shell script that is used to start pitond when the computer boots up is named "RetroClient", and it lives in that folder.

 

I don't know exactly what functionality the .plist file adds to things (besides the "Starting RetroClient" message that displays when the sytem boots, which was easily visable in early OS X builds but today screams past too quickly to even read), but the plist won't launch the process.

 

So, if the shell script isn't in /Library/StartupItems/ then there is nothing installed that can start pitond, yet you claim in your message that pitond _does_ start on system start, leads me to believe that you are not being accurate in your message (even though it is obvious that you are _trying_ to be accurate and complete).

 

Have you reinstalled the client software?

 

 

Dave

[rhwalker]

Ok, that's good information. pitond has crashed and hasn't been relaunched.

 

The new piece of information that I haven't seen reported in other problem reports is the proactive backup nature of the client.

 

Quote:

---

(6) cat /Library/StartupItems/Retro*

 

This command fails.

 

---

Sorry for my typo. What I wanted to see was the RetroClient shell file that starts the pitond daemon, to make sure that it existed and hadn't been modified. Here's what you should see:

 

Code:

---

rhwimac:~ rhwalker$ cat /Library/StartupItems/RetroClient/RetroClient

#!/bin/sh

 

##

# Start Retroclient (pitond) daemon

#

# please make sure this is saved with unix line endings

##

 

. /etc/rc.common

 

if [ -f "/Library/Preferences/retroclient.state" ] && [ -d "/Applications/Retrospect Client.app" ]; then

ConsoleMessage "Starting Retrospect Client"

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

fi

rhwimac:~ rhwalker$

---

Quote:

---

There is only one file in the /Library/StartupItems/RetroClient folder:

 

---

Um, are you sure about that? If so, we've got a problem that could be causing this failure.

 

Code:

---

rhwimac:~ rhwalker$ ls -al /Library/StartupItems/RetroClient

total 32

drwxr-xr-x 4 root wheel 136 Jul 3 2005 .

drwxr-xr-x 7 root wheel 238 Dec 5 2006 ..

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

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

rhwimac:~ rhwalker$

---

 

You could do a cron job to execute the RetroClient shell file (I would suggest putting a copy somewhere else, renaming it a different name, and doing that other version via cron because of the setuid issue). The problem is, it would have to be setuid root (when started up at boot, it is run as root, so this problem doesn't exist at that time). Make sure that it isn't world writable, or you would have a serious security hole.

 

A better way than a cron job might be to convert it to a launchd item, and then launchd would automatically relaunch it if it ever stopped running.

 

Russ

[rmcken]

That must have occurred during the latest uninstall/reinstall, I remember the shell script from poking around earlier and do remember pitond starting up on restart in earlier tests. I just checked and pitond does not now start up on restart, as expected without the script. I will check permissions to see if I can figure out why it's not getting installed, and, even if I can discern no direct cause, do another un/re-install and check that the script exists. And I thought I was being so careful! Thanks.

[rmcken]

Quote:

---

There is only one file in the /Library/StartupItems/RetroClient folder:

Well, that would be a problem.

 

The shell script that is used to start pitond when the computer boots up is named "RetroClient", and it lives in that folder.

 

I don't know exactly what functionality the .plist file adds to things (besides the "Starting RetroClient" message that displays when the sytem boots, which was easily visable in early OS X builds but today screams past too quickly to even read), but the plist won't launch the process.

 

So, if the shell script isn't in /Library/StartupItems/ then there is nothing installed that can start pitond, yet you claim in your message that pitond _does_ start on system start, leads me to believe that you are not being accurate in your message (even though it is obvious that you are _trying_ to be accurate and complete).

 

Have you reinstalled the client software?

 

---

 

I dug a little deeper (which I should have done first), and found a lot of errors when repairing the disk & permissions on the drive. After repairing a few times and still getting errors I resorted to reformatting the drive and dropped a new image on it (and checked permissions again, which looked ok). I then reinstalled the client. All the retro files are there and where they should be. The client has been running for a week now with no issues. Thanks for the support, and a note to self- try the basics first!

[CallMeDave]

Thanks for the update!

 

The pitond software is pretty well baked on PPC, and seems to work reasonably well under Rosetta, too. Reports of the client software turning off generally reveal causes other then software defects.

 

 

Dave

[rkhmn]

I have been having the problem of Retrospect Client turning itself off at random times and finally discovered why.

 

I am using OSX10.4.10 on G4 laptops. One is the host (6.1.126) and the other is the client (6.1.130). The client would shut itself off after 1 to 10 miinutes (as indicated by the radio buttons in Retrospect Client; the status message would go from Ready to In use by "root" for "Easy Script Backup" to error during startup when the radio button said off).

 

It turns out that both laptops had both Built-in Ethernet and Airport enabled, with built-in ethernet having priority. I thought this was safe, and that wireless would never be used. But turning off Airport on the client made the backup solid; turning airport back on makes Client quit randomly.

 

I hope this helps someone else!

[CallMeDave]

Quote:

---

I hope this helps someone else!

 

---

 

What it does is make clear that the Status message is vital to understanding what might be happening for some users. The "error during startup" message indicates a network issue, where Retrospect is unable to bind to a network interface.

 

It is possible to have both wired ethernet and wireless 802.xx enabled and have the Retrospect client work without error. I haven't tried to go through all the different configurations and steps to make it fail, so I don't know what works and what doesn't. Certainly, once the client is bound to wired, it would be unusual for it to try and "startup" again.

 

Your report indicates that during the 1 o 10 minutes you had performed a backup from the Retrospect application (as indicated by the change from "ready" to "in use"). Is that correct? Did the backup complete? Does the error occur only after a machine connectes to the client and completes a backup?

 

Dave

[rkhmn]

Hi Dave,

 

Thanks for the comments.

 

No, the backup does not complete. A backup typically takes half an hour or more. Sometime during the 10-20 minutes that it is Scanning the client hard drive, the client turns off: that is, the radio button switches from On to Off and the status box says "error during startup." The host Retrospect log says

Scanning incomplete, error 519 (network communication failed)

 

I, too thought that both wired and wireless could be enabled without a problem. But all I know is that the three times I have turned off Airport in the Client's menu bar, I have backed up to normal completion without a problem (though I confess that there was not much new for the incrementall backup the last two times). The dozen or so times that I have had Airport on (but with built-in ehternet having priority on both machines) I have had this connection failure problem occur after a few minutes, usually while still in the Scanning client phase.

 

Since I do backups manually, it is easy for me to turn Airport off first, so I feel that I have a satisfactory work-around. Someone who is trying scheduled backups at night might want to have their client turn off Airport before going home at night to see if it helps.

 

Again, I don't claim to have solved the basic problem, just that by accident I found a work-around that works for me.

 

Thanks again.

 

Russ

[rhwalker]

I wonder if the client has a short time-to-sleep setting, and is going to sleep at some point while Retrospect on the server is thinking. It might be instructive to crank the sleep setting out and see what happens then with both interfaces enabled.

 

(a different) Russ

[rkhmn]

No, I have it set to never sleep and for the display to never darken.

 

Russ

[fredturner]

Has anyone heard a peep from Dantz/EMC/Whomever about this recently? I've looked at my logs, and a few of the times where the client has turned itself off, I've gotten the -519 error, but not always. Many times, the clients just switch off and I simply have "Source" as the status in the Backup Server window. Anyway, EMC had a tech article about this some time back which said they were investigating it. I haven't seen any further info, and we haven't had a client update in forever, so are we just stuck w/ what we've got? Is the Mac version of (the originally Mac-only) Retrospect dead in the water???

 

Fred

[CallMeDave]

Quote:

---

Has anyone heard a peep from Dantz/EMC/Whomever about this recently?

 

---

 

About what, exactly?

 

This particular thread contains multiple reports, none of which really give enough descriptive information that would qualify as a true bug report. A client not starting at restart. A user with a sleeping Mac. A user with incorrectly installed software. A user with machines that sleep/wake while connected via AirPort (a known issue). A user with wired/wireless configurations.

 

Your previous report of:

 

> I's pretty easy to replicate. Just install the "latest software" ... on a server and a few clients,

> wait a few days, and you'll have clients w/ the Retrospect Client radio button set to "Off"...all

> by themselves.

 

is specifically disproved by Russ' report of never seeing the problem with multiple clients. Conditions necessary to replicate the issue you are having are not as simple as you describe.

 

And even though posters on this thread have been asked to provide the information provided by the Status field of the Retrospect Client application, you have seen fit to omit that from all of your previous posts. In fact, you have provided very little configuration information that might either point to a specific condition that triggers a software defect, or solve whatever user action that might be the cause. No matter how active EMC development might be, they can't fix a problem that they can't reproduce.

 

Folks on this Forum are happy to help; but we need solid information that we can compare against our own real world experiences. Information that holds up to testing and reproduction. "I believe it to be a fault of the current version" is not much for us to go on.

 

> Is the Mac version of (the originally Mac-only) Retrospect dead in the water???

 

All that has been announced by EMC is that there will be some sort of Jaguar compatibility release, based on version 6.1.x. Apple today announced 10.5 will be out on Friday October 26, 2007. We should know shortly what EMC is going to release.

 

Dave

[Mayoff]

Quote:

---

Apple today announced 10.5 will be out on Friday October 26, 2007. We should know shortly what EMC is going to release.

 

---

 

We are working on an update. As of today, Apple has not told us which build of 10.5 is the "final build", which makes it hard for us to do testing against the final code for 10.5. They have not provided developers with an update since last month.

 

We will have details on compatibility with 10.5 when the OS actually ships. I can say that so far, the update does not have a major impact on Retrospect.

 

We also have engineering reviewing the Client turn off issue. As Dave said, without an in-house environment that reproduces this bug, it is hard to fix. We do consider this to be a critical product we want to fix.

[fredturner]

Quote:

---

About what, exactly?

 

---

 

Thought I'd check this thread again to see what was up and... HOLY COW, you *STILL* steadfastly refuse to believe that all these people posting just maybe, possibly, potentially, have the teensiest chance of actually having a REAL software issue. Simply stunning.

 

Let's see..."about what, exactly?" you ask. Oh, perhaps the technical article that I referred to in my previous post??? Think that *might* be it? Or would you rather just increment your prolific post count by haughtily refuting yet another person's post? I'd like to see if you could actually be more antagonistic and doubtful of what we mere idiots who are not worthy of being in the presence of your vast knowledge have to say. Probably not.

 

For anyone else who might like to actually try to help, or share info and updates about this obvious problem (whether Dave has a flow chart of how to replicate it or not), the year-and-a-half-old tech article is here:

 

http://kb.dantz.com/display/2n/kb/article.asp?aid=9512&n=5&s=

 

THAT is what I was asking if there'd been any news about. But probably a URL isn't specific enough, right? How did I link to the URL? How did I enter it in this post? Did I hand type or copy-and-paste? What browser did I use? Was it dark outside???

 

No, I'd just like to know if EMC was planning on following up on IT'S OWN tech article that SPECIFICALLY addresses the problem that many of us on this thread are having. Mayoff, I appreciate your mentioning that it is being looked at, but that's about the same as what's said in that tech article (in 5/06). It would be great to hear any new info if you can provide it.

[CallMeDave]

Quote:

---

you *STILL* steadfastly refuse to believe that all these people posting just maybe, possibly, potentially, have the teensiest chance of actually having a REAL software issue

 

---

 

Well, I suppose that you're referring to me. To which I say, duh, of _course_ I believe that people posting might possibly be having real software issues! That's why I've posted 3,400 messages to this Forum; to "actually" try and help people with whatever problems they might be having!

 

But I also recognize that issues with usability are not always software defects, so information about exactly what the user is seeing and doing is critical for "actually" helping people.

 

> Let's see..."about what, exactly?" you ask.

 

Correct. As I noted, this specific thread has branched to multiple issues. Re-read my post upthread (#100756) that explained why I asked what problem, exactly, you, specifically, were talking about.

 

 

> For anyone else who might like to actually try to help, or share info and updates about this obvious problem (whether Dave has a flow chart of how to replicate it or not), the year-and-a-half-old tech article is here:

 

For true? That was the "this" you were asking about? The KB article that I myself linked to in the 10th post to this thread? Not the issue that Mayoff linked to in the 8th post to this thread? How could _anyone_ have known??

 

Yes, waking a client that has no wired ethernet connection is a problem that may continue to be unresolved.

 

Describing it as a client "turning itself off" would be inaccurate, though, as the issue is that the client, which goes off when the computer goes to sleep, just as all unix daemons do, does not come back alive reliably when the Macintosh wakes under some configurations.

 

 

> Is the Mac version of (the originally Mac-only) Retrospect dead in the water???

 

No! I just got back from Macworld in San Francisco, where I saw an actual Universal Binary of the Retrospect Mac OS X Client software! It's not available yet, but as I understand it there will be a public beta coming in the near future.

 

In addition, they were showing a demonstration of a completely new build of Retrospect, dubbed "Retrospect X" that is under development. EMC is a large corporation, well known for delivering software to customers, so I have no reason to doubt that they are putting the engineering resources in place to do this right. Yeah!

[fredturner]

That's good to hear about the MWSF demo, Dave. It's been so long since any significant development has happened on the Mac side (while the Windows version just keeps getting upgraded & updated), I had figured that we were probably at the end of the Retrospect-on-Mac line. Hell, I'd be glad if the only new feature was the multi-threading that Windows has...it's so disruptive to have to interrupt a backup if you have one small change you need to make! Anyway, thanks for the news.

 

Okay, now that we know what each other is talking about: you previously mentioned wanting to know the Status field in the Retro client. When I see this issue, the radio button up top is, of course, "Off", and the Status field shows "Not running". Clicking the button to On immediately fires the client back up and the server can immediately "grab" it for a backup.

 

One interesting thing I'm seeing, though, is that this issue isn't confined to wireless-only clients. I have several iMacs here that are Ethernet--ed, and just had to turn one of them back on a few minutes ago.

 

Mayoff, if you have trouble recreating the problem there and need to see it in its "native habitat", I'll be glad to show you around Birmingham.