CallMeDave Posted January 16, 2008 Report Share Posted January 16, 2008 Quote: I have several iMacs here that are Ethernet--ed, and just had to turn one of them back on a few minutes ago. Is it possible that the machine had been restarted at some point? If you restart one of these machines, does the client come alive as it should? Quote Link to comment Share on other sites More sharing options...
rhwalker Posted January 16, 2008 Report Share Posted January 16, 2008 Quote: 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. Interesting. The datasheet that is downloadable from the EMC Insignia home page at: EMC Insignia home page (wait for the Flash graphic to cycle to "Visit us at the Macworld Expo ...", then click the "download the Retrospect for Macintosh datasheet") mentions, at the bottom of the first page and at the bottom of the second page, that: Quote: "Retrospect for the Macintosh 6.2 Client is now Universal Binary. Sure sounds like the marketing types believe that it's far beyond "beta". I would hope that it's well-tested before it touches my data. Russ Quote Link to comment Share on other sites More sharing options...
hideobobo Posted January 31, 2008 Report Share Posted January 31, 2008 Quote: 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. I have been having a similar issue with clients mysteriously turning off on their own. One thing I am noticing that is somewhat related to the latest postings is that ANY change to the active network connection (whether it is wired or wireless) will switch the client off. I tested it with a PowerMac G4 (QuickSilver 800MHz) running MacOS 10.4.11 and RetroClient 6.1.130 and ethernet (DHCP) initially plugged in, and no wireless card at all installed. Computer starts up, client is on and shows a status of "Ready", and is accessible from the server (6.1.138). Once I unplug the ethernet, about 10 seconds later, client turns off, and status goes to "Error during startup". I plug the ethernet back in, but client remains off. Once I go into the client and manually switch it back on, this re-establishes accessibility from server. With a static IP, when I initially unplug ethernet, the client turns off briefly, flashes "Not running" for a second, then actually comes back on and to "Ready" status. But when I plug the ethernet back in, client then turns off, status is "Not Running". On a MacBook Pro running MacOS 10.4.11 and RetroClient 6.1.130, same thing happens with ethernet, or when I toggle the AirPort on or off...client switches off. Thoughts? This couldn't be normal, could it? Quote Link to comment Share on other sites More sharing options...
rhwalker Posted February 1, 2008 Report Share Posted February 1, 2008 That's remarkably good troubleshooting, and seems to be the most concise statement of the cause that I have seen, and produces a repeatable event. It also may be why we don't see this issue at our site, because I've put real effort into making our network fast and reliable - it's necessary when you have network home directories and very little stuff on the client computers. No, it's not normal, and the client ought to handle this more gracefully. Russ Quote Link to comment Share on other sites More sharing options...
hideobobo Posted February 4, 2008 Report Share Posted February 4, 2008 Russ, I only wish my department could have more authority to institute a centralized setup like that...would certainly make backup a little more manageable. But users here just love to hold on to data on their local machines...a sentiment I guess I can sympathize with, to some degree. Okay, so it's not normal (and good to hear it, it's not just my hallucination, or my network), so I tried testing some more variables... Taking the same PowerMac G4 listed in my previous posting, I physically took out the 10.4.11 boot drive altogether and put in its place a hard drive with MacOS 10.3.9 installed. Installed Retrospect Client 6.1.130 and rebooted. With ethernet plugged in before bootup, machine starts up, client is on, successfully acquired on Retrospect Backup server 6.1.138 and shows status of "Ready". Now, when I unplug the ethernet, the client briefly shuts off, flashes a status of "Not running", but then turns itself back on, and goes right back to status "Ready". When I plug the ethernet back in, same thing...client shuts off, but then comes right back on. I imagine this should be the normal behavior of the client software, but apparently is not happening in 10.4.x and gets stuck in the off position right after the network connection change. Also note...I say 10.4.x and not just 10.4.11 because I took a separate, completely formatted drive, installed 10.4.6 straight from the installation DVD, rebooted, downloaded and installed Retrospect Client 6.1.130, rebooted again, and the same thing happens with the client shutting off and staying off once the ethernet is disconnected. Nothing else was installed, no antivirus, OS or security updates. I also observed the same problem on a PowerMac G5 (1.6 GHz) running MacOS 10.5.1. I was thinking maybe an older version of the client might work (even if it wouldn't matter for Intel Macs), but apparently the same problem exists (not to mention I couldn't find an installer for 6.1.107 anywhere): http://forums.dantz.com/ubbthreads/showthreaded.php?Number=81058&page= Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted February 4, 2008 Report Share Posted February 4, 2008 Quote: so I tried testing some more variables... Me too. Give me a second to pick up the pieces of my head, which has exploded... iMac G5 Mac OS X 10.4.10 "OfficeiMac" Retrospect Client 6.1.130 - Open Console, select /var/log/retroclient.log - Open Activity Monitor, type search string "pitond" - Open Retrospect Client.app - Configure all windows to see information as it changes. - With pitond alive, Retrospect Client radio button "On" and Status field "Ready,"retroclient.log reads: 1202167122: PmcOpen: connect() failed with error 61: Connection refused 1202167122: ipludAddMembership: adding membership for 0.0.0.0 1202167122: iplud: bound to address 29.1.168.192 1202167128: IPNSRegister(0): registered: "OfficeiMac"/"72gw857b09c2ev12" 1202167134: IPNSRegister(0): registered: "OfficeiMac"/"72gw857b09c2ev12" 1202167134: bindToValidBootPort: gServerPID has been initialized to 94 (note; the actual value of "72gw857b09c2ev12" is different, but since I don't have any idea what that information is I randomized it for use on the internets) Some of the log is obvious; IP address for this machine on its local network is 192.168.1.29, date is February 4, 2007 (~ 1.2 billion seconds since the epoch) and file sharing name is, as noted earlier, "OfficeiMac" - Pull ethernet network cable. - pitond disappears from Activity Monitor, radio button in Retrospect Client changes to "Off," status field displays "error during startup" and the following is appended to the retroclient.log file: 1202167816: connAccept: close(socket) failed with error 9 1202167816: Assertion failure at pitond/object.c-477 1202167816: LogFlush: program exit(-1) called, flushing log file to disk All well and bad. Plugging the network cable back in has no effect. HOWEVER - With all other conditions the same, repeat test with the Retrospect Client application window closed. - Pull network cable - pitond remains listed in Activity Monitor - the following is appended to the retroclient.log file: 1202168229: ipludAddMembership: adding membership for 0.0.0.0 1202168229: iplud: bound to address 1.0.0.127 1202168235: IPNSRegister(0): registered: "OfficeiMac"/"72gw857b09c2ev12" It appears that pitond has changed its binding to 127.0.0.1, which would be the address of the machine off the network! - Plug the network cable back in - The following is appended to the retroclient.log file: 1202168266: ipludAddMembership: adding membership for 0.0.0.0 1202168266: iplud: bound to address 29.1.168.192 1202168272: IPNSRegister(0): registered: "OfficeiMac"/"72gw857b09c2ev12" The client software has now successfully changed its bindings back to 192.168.1.29, and the machine is accessible over the network by Retrospect! So the very act of using the client application to monitor the activity of the client software effects the behavior of that software. Isn't there some physics phenomenon for this? Heisenberg? Schrodinger cat box? Quote Link to comment Share on other sites More sharing options...
hideobobo Posted February 5, 2008 Report Share Posted February 5, 2008 Haha well, whatever we label it, that's a good call by you, CallMeDave. (And personally, I did NOT enjoy physical/quantum chemistry back in the college days, so you're on your own for the naming). I see the exact same thing on my end. I even tested it with toggling AirPort on and off, sleeping the machine...pitond remains active as long as the Retrospect Client window isn't open at the time of network change (I monitored it by having the retroclient.log file open in the background with Console). Maybe PPC v. Intel would yield something else? That is, does the Client shut off on an Intel box on a network switch, regardless of the Client window being closed? I'll have to find an appropriate test environment and report...it's the very reason I brought it up in the first place: my initial observation was random shut-off of the 6.1.130 client on a MacBook Pro running 10.4.11. So then, initial conclusions? For me, it seems like we can file this as a peculiar bug in the Retrospect Client 6.1.130 within Tiger and Leopard that needs a fix, but not necessarily _the thing_ that's causing the Client to shut off randomly...at least, not with a PPC-based client machine. I mean, I guess maybe a handful of people are leaving the Client open to see what's going on with the status (on v. off), but I would imagine the vast, vast majority of users that I back up don't even realize/care the Client is installed, and they hear about backup failure/inaccessibility from me directly. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted February 5, 2008 Report Share Posted February 5, 2008 A beta of the new Universal Client will be out in the near future. You can test how the new version works and report feedback at that time. Things should work better with the new client. Quote Link to comment Share on other sites More sharing options...
fredturner Posted February 5, 2008 Report Share Posted February 5, 2008 Hey Guys-- Nice scientific testing there, Dave & Hideo! While I haven't yet resorted to those types of elimination & observation techniques myself, I have noticed more "bad behavior" to comment on. It does *seem* to me like it has a lot to do with whether or not the client machine has more than one network interface. I don't recall my Ethernet-only G5 at home *ever* turning its Retro client off. Same w/ some client Mac Pros. But several of the iMacs I've set up at another client exhibit the symptoms, even with the AirPort disabled. I know that's not very helpful and not very specific, but my point is that it does seem to me like the number and/or type of network ports may be a contributing factor. Dave, from what I've seen, restarting these machines does cause the Retro client to turn itself back on. I noticed this earlier on my 10.5.1 PowerBook G4. It had apparently been off for a bit, but when I restarted after installing a security update, Retrospect immediately tried to back it up. Quote: A beta of the new Universal Client will be out in the near future. You can test how the new version works and report feedback at that time. Things should work better with the new client. Thanks for the update, Mayoff! That is encouraging. I hope the new client will improve existing situations as well without requiring a server upgrade (yet). Any clues as to what "near future" might mean? Weeks? Months? Thanks, Fred Quote Link to comment Share on other sites More sharing options...
hideobobo Posted February 6, 2008 Report Share Posted February 6, 2008 Quote: Hey Guys-- Nice scientific testing there, Dave & Hideo! While I haven't yet resorted to those types of elimination & observation techniques myself, I have noticed more "bad behavior" to comment on. It does *seem* to me like it has a lot to do with whether or not the client machine has more than one network interface. I don't recall my Ethernet-only G5 at home *ever* turning its Retro client off. Same w/ some client Mac Pros. But several of the iMacs I've set up at another client exhibit the symptoms, even with the AirPort disabled. I know that's not very helpful and not very specific, but my point is that it does seem to me like the number and/or type of network ports may be a contributing factor. Well, it's another variable I had been thinking about...so working from Dave's observation, if the Retrospect Client window is open (in the foreground or background), and the active network connection is changed in any way, what are the various factors that trigger the Client to shut off? --A PPC machine running Panther, the 6.1.30 Client works normally. --A PPC machine running Tiger or Leopard, the 6.1.130 Client will shut off. --An Intel machine running Tiger, the 6.1.130 Client will shut off. --An Intel machine running Leopard, the 6.1.130 Client may or may not shut off.* *I have been testing the last situation, and I can't get the Client to fail as regularly as the others. Toggle wireless on/off, unplug ethernet, switch between locations that have only ethernet, only wireless, or all interfaces active, the Client is pretty resilient under Leopard on an Intel box. And it might also depend on the specific Intel hardware; on a MacPro tower, for instance, the Client would switch off maybe once in a million changes, an Intel iMac (CoreDuo, not Core2Duo) would switch off slightly more frequently, but not much. Fred, Yes, a reboot would help by resetting everything, including switching the Client back on, but only so long as the network connection after the reboot remains in place and does not change. The only problem with this...most people with a laptop don't shut down when taking it someplace else, they just close the lid (and put it to sleep, in effect) and go. This will eventually disrupt the Client since they are unplugging ethernet (presumably), and based on the situation matrix above (as far as I can see and test, anyway). Mayoff, Thanks for the update, it certainly is encouraging to hear that support for Retrospect is ongoing and developing. I can't think of what I would do in place of Retrospect, considering how many workstations and servers I back up (tens of terabytes of data, easily). My department has a Connected DataProtector server and they are supposed to release a Mac beta version at some point, but I can't trust it (the software or my colleagues who administer the server...sad but true). I don't mean to beat a dead horse with all this testing, since you say a new client version release is imminent, but I need to at least attempt to identify the particulars of this issue and make people aware of it (especially my department's directors) so we can make some contingency plans. And, as you can see, I'll be more than happy to test it across different hardware/software situations and report findings. Hopefully someone else will find it useful on this forum. I know I'm glad I read and posted. As it turns out, the solution to my original problem...the person had the Client open in the background all this time. Of course, she didn't realize it, since it was buried behind about 50 other windows... -Brian good ol' New York, NY Quote Link to comment Share on other sites More sharing options...
Churchill_Blair Posted April 22, 2008 Report Share Posted April 22, 2008 Read through the thread here... I'm seeing essentially the same issue on my system. Mac Retro Server (6.1.138) talks to one client machine fine and doesn't have issues, but the other client it backs up will give me error 519 (network communication failed) on copying files, and on subsequent backup attempts will give error -1028 (client not visible on network) -- before finding this discussion thread, I did discover on my own that on the client machine, the client software displays as "off" The machine running Retro Server is a G5 XServe, running 10.4.11, and both of the clients that it backs up are Intel XServes running 10.4.11... both the server and client machines are connected to the core switch in our server room via dual teamed-NICs for maximum bandwidth. I haven't found anything useful in that KB tech-note on the 519 error - my network topography is flat and the server and client are talking to eachother over 2Gbps cat6 cable through a gigabit switch, so there's no reason there should be a drop in network connectivity. I subdivided my backup-client volumes a number of times, so I do think I found the folder(s) that retrospect is dropping out on the copy -- I have yet to do any more thorough disk checking to see why I'm getting that error 519 in the first place, but I did want to add my situation and client-server setup to this thread in the hope that it helps. thx B Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted April 22, 2008 Report Share Posted April 22, 2008 ...on the client machine, the client software displays as "off" Directly below the "on" and "off" radio buttons is a fairly expansive field labeled "Status." - What is displayed in the Status field of a client that is not being seen? - Do you see any logs for Retrospect Client or "pitond" in the /Library/Logs/CrashReporter/ folder? - Do date/time stamps in the logs match the date/times in your Retrospect Operations Log? There is an ongoing beta program for a new version of the Retrospect OS X Client software, rebuilt as a Universal Binary application. You might want to give this software a try. Dave Quote Link to comment Share on other sites More sharing options...
paul_bruneau Posted April 24, 2008 Report Share Posted April 24, 2008 (edited) What a weird thread. So anyway, I have an aluminum imac running 10.4.11 (retro client 6.1.108) which uses wifi to connect to my network. The user manually puts the computer to sleep at night and wakes it up in the morning. A backup I have scheduled for the morning after the wake up time almost never runs. I walk down to his office, and find the Retro client set to "off". I turn it on, manually run the backup and it is fine. Until tomorrow. When the client is "off" again. Is it true that Dantz/EMC/Whoever owns this place can't reproduce this problem? Also, I'm quite geeky being a 15 year Mac admin and Cocoa programmer but I don't care what pitond is. I care that a switch that I turn "on" turns itself "off" every day. Edited April 24, 2008 by Guest Quote Link to comment Share on other sites More sharing options...
Mayoff Posted April 24, 2008 Report Share Posted April 24, 2008 Paul, These issues should be fixed in the Universal Client Beta. Please download and try the beta, it will probably fix this problem; if not, your feedback will help us fix it before final release. Details are in the beta section of the forum. Quote Link to comment Share on other sites More sharing options...
paul_bruneau Posted April 24, 2008 Report Share Posted April 24, 2008 Thank you. I would be happy to do that, but I see that I must use the beta version of the Retrospect Application itself in order to use the beta client. This makes me nervous. Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted April 24, 2008 Report Share Posted April 24, 2008 Is it true that Dantz/EMC/Whoever owns this place can't reproduce this problem? No, that is not true. In fact, EMC Insignia (who has owned this place for a couple of years now) has a Knowledge Base article about it, last dated almost two years ago (5/12/2006). And a year and a half later I added Post#83649 to this weird thread reminding readers that this was a known issue. Quote Link to comment Share on other sites More sharing options...
paul_bruneau Posted April 25, 2008 Report Share Posted April 25, 2008 Now I can die secure in the knowledge that I have been put in my place by the best. Thank you, CallMeDave, for your response! I didn't trust that the knowledge base article applied to me, since I had read people in this thread who had the problem who were not wireless. And even if it did apply to me, where was the answer?! Apparently the answer (at least at that time) was to walk my butt to the client and turn it back on every day. As for your very helpful post #83649, all I see there is more of your apologist ranting and typical behavior of blaming the victim. I saw no reminder that is was a known issue. But go on thinking how superior and perfect you are, and how dumb all of us with this problem are, if it makes you more comfortable. Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted April 25, 2008 Report Share Posted April 25, 2008 Thank you, CallMeDave, for your response! You're welcome. You seemed to have been sincere in your question as to whether or not the Retrospect engineers had reproduced the specific problem that you reported. I am glad that I was able to answer that question for you, and to direct you to additional information on the matter. I didn't trust that the knowledge base article applied to me, since I had read people in this thread who had the problem who were not wireless. I'm afraid I don't follow your reasoning here. - A known condition (sleeping/waking with wireless only connection) is documented to cause a specific software failure (a switch that you turn "on" turns itself "off"). - Others, with different conditions (both known and unknown) also observe a failure that appears, on the face, to be similar. - Therefore, your known condition might somehow _not_ be the cause of the failure? That the existence of the other users somehow effected how your software behaved? ...where was the answer?! Apparently the answer (at least at that time) was to walk my butt to the client and turn it back on every day. Correct. At the time, the known issue had no known solution. ...all I see there is more of your apologist ranting and typical behavior of blaming the victim. No matter. Most great artists aren't really appreciated until after they're dead. The purpose of that specific post was to _try_ and make some sense of just how "weird" the thread had become, by listing some of the different conditions provided by the different contributors. I don't think it quite rose to the level of ranting, although I agree that I did blame the poster for leaving out relevant information that had been specifically requested. Whether or not that poster considers himself/herself a victim is not for me to say. And other then my egregious error of calling Leopard Jaguar by mistake, the post was accurate in noting that EMC was going to announce something new, and 12 weeks later they did just that, with public distribution of a beta client following a few weeks thereafter. I saw no reminder that is was a known issue... In context, my statement was: This particular thread contains multiple reports... including... A user with machines that sleep/wake while connected via AirPort (a known issue) I don't know how the new Unicorn client behaves with sleep/wake conditions on wireless only machines. I haven't tested myself, and haven't seen a post regarding it on the Beta section of the Forum. But I am glad to have revisited this thread, if only to be reminded to test the steps I noted in Post# 83659 to see if _that_ very weird behavior has changed. Dave Quote Link to comment Share on other sites More sharing options...
fredturner Posted July 1, 2008 Report Share Posted July 1, 2008 Playing a little bit of catch-up here... Is this issue supposedly fixed w/ the new client version I see, 6.2.229? Of course, I'm gonna go try it, but just wondering if a cure is to be expected... *crosses fingers* Thanks! Fred Quote Link to comment Share on other sites More sharing options...
Mayoff Posted July 1, 2008 Report Share Posted July 1, 2008 Yes it should be fixed in the 6.2 client. If you do run into problems, we want to gather a debug log to track down a possible cause. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.