Jump to content

cwwade3

Members
  • Content count

    14
  • Joined

  • Last visited

Community Reputation

0 Neutral

About cwwade3

  • Rank
    Occasional Forum Poster
  1. I assume you are correct in your statement that the client application process is crashing. I have not seen this in the logs, but then I haven't gone looking. I'm reporting the observable state from the GUI. I could also imagine that some other state change is taking place that causes the client to be turned off. To be honest, I've always found Retrospect to be one of the most painful applications to debug problems with. I've lost most of my patience with it. I just try to minimize problems, and I'll agree that, when left alone, it usually works fine. However, I can't ever remember an upgrade that's gone smoothly, so I tend to be extra cautious. In this case, I'm glad I did approach things slowly.
  2. I'm just noting that I've seen a similar problem. In order to try some experiments relating to the problem with clients turning off on their own, I tried to activate a client that I haven't bothered to back up in some time, as it is not actively used. It is another PowerBook running OS 10.4.11 with retroclient 6.1.130. I got the same problem as reported by Binford--i.e., "Activator code x-xxxx-xxxx-xxx is used for multiple clients." The old IP address that used to be used by this PowerBook was reported along with its current IP address. Due to some changes in my network, it is not convenient to give the PowerBook the same IP address it had previously. I had first tried to access the client PowerBook by its name from the Retrospect server, but instead received the error notice, "Sorry, can't connect to client ClientName error -1028 (client is not visible on network)" I cannot find anyway to "forget" this client, or to remove it from the client database. If I try to add it by its current IP address, then I get the multiple activator code error condition. This seems to be a bit of a catch-22.
  3. Since I started this thread, I should probably provide an update. To resolve the problem I had with the 6.2.229 client turning itself off, I uninstalled it and re-installed the 6.1.130 client. Note that these operations were performed directly on the target PowerBook--i.e., I did not perform the update remotely via the Retrospect server. The server is still the latest 6.1.230 version. At first, I thought the problem was resolved. However, over the past month and a half, I've noticed that the 6.1.130 client still turns itself off, but much less frequently than the 6.2.229 client. Instead of turning itself off within an hour or so, it is now only every few days, maybe about once per week. A key point is that this problem was never seen before in many years of running the same PowerBook. There is some correlation with events like putting the PowerBook to sleep, or going on the road with it so that network settings change. However, I can't find any clear correlation. In other words, sometimes the client turns itself off after putting the PowerBook to sleep or going on the road, and sometimes it does not. Furthermore, I've observed the client turn itself off even when the PowerBook has remained on constantly at my normal desk location. Ditto for restarting the PowerBook--sometimes it cause the client to turn off, and sometimes it doesn't. I don't know what to conclude from this, but it does seem to indicate that there might be some relationship to the new Retrospect server, as this is the only thing that has changed. Again, I never saw this problem until I performed the latest Retrospect server and client upgrades. Thank goodness that I only updated the client on one PowerBook, since the other clients remain stable.
  4. I already have the PowerBook client set up so that the built-in Ethernet is preferred, and Airport is turned off entirely. Note, at this point, I'm not sure whether the problem is on the client side, or the server side. Since this problem only shows up when running a backup script on the server, it is quite possible that the problem is in the server's logic. For the record, the server has only Ethernet, and no other network interfaces are configured. Static IP addresses are used by both client and server.
  5. It appears that pitond is no more. In its place, I'm seeing a new process name, retropds.24, and also a rectroclient process. I observed on one PPC client running the 6.2.229 client software six instances of the retropds.24 client, but only one instance of the retroclient process. I'm bringing this up here, as I haven't seen this mentioned anywhere else, and I find no reference to these changes in the release notes for the latest Retrospect software for Macs (6.1.230 server and 6.2.229 client). While this is "under the covers" stuff, it would be helpful to have some documentation detailing what processes are supposed to be running on clients. Certainly, there are many posts in this forum that deal with pitond operations and expected behavior. As a long time user, I'd be interested in knowing whether the new client processes are essentially the same as the one's we've gotten used to, or if there are fundamental differences. When I need to debug what's going on, what should I expect to see? Because this information has been relevant in the past, I'd also like to know what the bootup sequence is supposed to be, and when the Retrospect processes get started. Similarly, it would be nice to have some documentation on what log files are used, and where they are located. Yes, I can figure this out, and have, but it would be nice to not have to go exploring when there are always more pressing things to be doing.
  6. In looking through some other posts, I realize I should clarify a few other points. First, in this problem report, the Backup Server is a PPC machine (PowerMac G4 dual 500 Gigabit) that runs 24x7 (and has for eight years). The PowerBook is on the same LAN, which is wired and running at 100 Mbps. The PowerBook is a Pismo with 1GB of memory (another machine that runs non-stop, and has served very well for eight years). The PowerBook does not sleep when connected to AC power. It does not use it's wireless connection for backup operations. Generally, the Airport service is turned off, and it definitely was for these tests. As stated originally, both PowerBook and PowerMac are running 10.4.11 with latest patches.
  7. No, I do not find any instances of crash report logs for the Retrospect client on the PowerBook. I checked all locations for crash reports. I did conduct some additional experiments. I turned the client back on on the PowerBook while the backup server was active. It did find the client, and then successfully backed up the "B" volume from this PowerBook. However, after scanning the "A" (system) volume, it stopped, and the client turned itself off and displayed "Error During Startup" in the status window. I tried this several times with the same result. It would appear to finish scanning the volume, and then quit. On the Backup Server, the log shows the following error for this client and volume: [color:purple] > scanning incomplete, error 519 (network communications failed)[/color] I then tried doing an immediate backup of this volume from the same server. Everything worked as expected, with the one noticeable difference that the scanning process took much longer, and scanned many more folders and files. The backup was successful. I checked the Retrospect client logs on the PowerBook. The history file is unsurprising, and the retropds.log file mostly reports "MXUToMac: CFStringGetCString failed" messages, which I doubt are significant. However, the retroclient.log file does show some trouble. I've copied the start of this log file below: [color:purple]1216570453: Main: Client version is 6.2.229 1216570453: NetStart: starting interface thread 1216570453: netCheckNewInterfaces: found new address 127.0.0.1:0 1216570453: ConnStartListen: starting thread ConnStartListen for 127.0.0.1:0 1216570453: netCheckNewInterfaces: found new address 172.24.12.131:0 1216570453: ipludAddMembership: adding membership for 172.24.12.131 1216570459: IPNSRegister(0): registered: "Robinton","beef3a5024f4eec1","0.0.0.0:0" 1216570459: ConnStartListen: starting thread ConnStartListen for 172.24.12.131:0 1216570460: bindToValidBootPort: gServerPID has been initialized to 8878 1216570621: Connection established by 172.24.12.130:49538 1216573123: connTcpConnection: kPiCodeClockSync failed 1216573742: ConnReadData: Connection with 172.24.12.130:49538 was reset 1216574468: bindToValidBootPort: Unable to bind to valid boot port 1216574469: bindToValidBootPort: Unable to bind to valid boot port 1216574470: bindToValidBootPort: Unable to bind to valid boot port 1216574471: bindToValidBootPort: Unable to bind to valid boot port 1216574472: bindToValidBootPort: Unable to bind to valid boot port[/color] At the beginning of the retroclient.log are the records for the normal "immediate backup" mentioned above. Note that the "bindToValidBootPort" was successful. I had previously noted failures for this bind operation in earlier examinations of this log (it appears this log file is cleared when the client is restarted). However, after a period of time, the "Unable to bind" errors started showing up on a regular interval (it seems once per second). These continue ad nauseum. Turning off the client does not stop these error messages from showing up in the log file every second. To confirm, in the above retroclient.log listing, 172.24.12.130 is the backup server, while the PowerBook is at 172.24.12.131. Obviously, something's not right, but I'm not sure where to go looking next. I will emphasize again that the only thing that has changed is the version of the client installed on this particular PowerBook, as well as the version of the Backup server (see original posting).
  8. I am having a problem with the new 6.2.229 client for Mac OS X, which turns off on its own for some reason. I can turn it back on, but before it gets backed up via the Backup server, it is turned off. However, I can turn it on and perform an immediate backup without any problems. Each day, I find the client has turned itself off, and the status shows "not running." When I turn it on, it shows "Ready," and my history is viewable. I should also note that I've been running Retrospect on the same basic hardware setup for about 7 years, and with the current software configuration for a couple of years. The backup server and the client PowerBook are both at 10.4.11 with the latest patches. I recently installed the 6.1.230 server software update, and updated the client on just one PowerBook to 6.2.229 from the server client config screen. However, this was before the 7/12 fix to the client updater file. To resolve the resulting problems with the client on the PowerBook, I uninstalled it, then reinstalled it using the Vise client installer directly on the PowerBook. I also "forgot" the client on the server, and re-activated it. The client is now much better behaved, and I can perform immediate backups. The problem is that something is causing the client to turn itself off. On running the client GUI on the PowerBook, I am getting the following reports in my console log: [color:purple]2008-07-19 12:02:27.320 Retrospect Client[20155] CFLog (0): CFPropertyListCreateFromXMLData(): plist parse failed; the data is not proper UTF-8. The file name for this data could be: /Applications/Retrospect Client.app/Contents/Resources/English.lproj/ctrlPanelUI.nib/objects.nib The parser will retry as in 10.2, but the problem should be corrected in the plist. Usage: retroclient [--help] | [-setpass | -log n | -ip n][/color] So, it looks like there is a corrupted plist file. However, why did the uninstall and reinstall procedure not correct this? Before proceeding with upgrading other clients, I'd like to understand what's going on here, and not cause further problems. I'd also like to be able to upgrade other clients remotely from the server. Until this gets resolved, I'm better off waiting. For the record, everything else appears to be working normally for both Mac and Windows client backups. I'm not even sure what benefits I get from running the latest client, at least on PPC machines. Aside: Thanks for fixing the "posted" date for the 6.2.229 client download on your web site. However, I'd recommend making the same change for the 6.1.230 server upgrade download, since it also includes the client installer that was fixed on 7/10. Anyone who downloaded the server software before the 12th would not realize that they had an outdated installer.
  9. Just a heads up. I tried re-downloading the latest 6.2.229 client software install dmg, and noted that the Mac_X_Client_Update_6_2_229.rcu file in this download is now dated 7/10/2008. However, the download page still says that the file is for 6/30/2008. If I hadn't seen another posting, I would have had no idea that there was an update for this installer. I am now going through a uninstall followed by a reinstall procedure. I'll see if this corrects the problem, as it appears to be related to having installed from the latest server issued on the 6/30 date.
  10. You indicate that there is an updated rcu file for the client installer on the Retrospect web site, but I can't find it. The only item listed was posted on 6/30, not last Friday. Is this just a problem with the date listed on the web site?
  11. I am having a similar problem with the latest Mac client software (6.2.229). What I observe is that the client interface shows that it is off, even though it had been previously set on. It appears that it will stay on for a while, and then turns itself off. This is directly related to upgrading to the latest client software. The host OS is 10.4.11 with latest patches. I was able to perform one immediate backup using the new Retrospect client, but scheduled backups do not work because the client is always turned off when the scheduled backup starts. I have also noticed that the Retrospect client software is no longer able to run from a non-administrator account. I normally run in a non-admin account, but have to switch to an admin account to activate the Retrospect client. Even when leaving the admin account logged in, the client sw turns itself off at some point. I have re-installed the client software directly on this machine from the admin account (and restarted the system). I initially upgraded the client software via the Retrospect server. Prior to the re-install, I could no longer turn on the client at all. The GUI would set the radio button on, and it would immediately switch back to off. After the reinstall, I could at least turn it on, but it won't stay on. Solution for the moment is to fall back to the previous version of the client software.
  12. Just to add another perspective on this problem, I have observed a similar situation when backup up local files to an internal Pioneer DVR-107. However, the system configuration is a PowerMac G4 DP/500 (Gig Ethernet, c. 2000) running Mac OS 10.3.8 with RAID 0 (hardware) drives. Backing up a series of large disk images (average size of 6GB), I observed that only about 3GB were being written to the DVD-Rs on average. Furthermore, the time to write the DVD's was extraordinarily long. By comparison, Toast can write a file to a DVD-R on this drive in under 20 minutes, while Retrospect was taking over an hour per DVD. This simply does not conform to expectations for enterprise class software. Are there any suggestions for how to debug what is going on? The Retrospect Log was not very helpful.
  13. Thank you for posting this fix. I have been pulling my hair out trying to figure out what was causing these assertion check errors. In my case, it was a single client that caused the problem. Any attempt by Retrospect to access this client would cause the application to crash with this error message and elem16.c-687 error code. I've been running my backup scripts by unplugging the client computer from the network. For the record, when checking clients, this problem client (a Windows XP system) shows up as "responding," and it can be selected and the configuration dialog box brought up with the "General" tab. However, clicking on either the "Configure" or "Volumes" tabs would result in the same elem16.c-687 error, and Retrospect would crash. However, as you note, the problem is easily fixed by "forgetting" this client, and then re-adding it back as a known client. I would think this problem could be pretty annoying to someone who was running an enterprise-wide backup operation. I've only got a half dozen clients, and I found it pretty debilitating for the Retrospect application to crash with every attempt to run my backup script.
  14. In the hopes of helping others out, I'm passing along a tip that resolved my problem with clients not showing up. I had the problem where no clients (Windows or Macs) on my local Ethernet would show up in Retrospect Desktop under Mac OS X (10.2.4). I had gone through all the troubleshooting checks, and everything was as it should be, but no clients would appear. Based on hints from this thread that Airport networking could be a source of problems, I went back to my "Netwok Port Configurations" (Network Panel in System Preferences), and tried unchecking the Airport Port. Immediately, I saw clients appear in the Retrospect Network Panel that happened to be visible on my screen. Everything now works. Note that I had my Ethernet port at the top of the list, and the Airport service was actually turned off. In other words, all my clients were on the Ethernet subnet and Airport was not being used. This strikes me as a bug in either Retrospect or Mac OS X. I should not have to turn off the Aiport nework port. For the record, I'm using a PowerMac G4 MP 500 for the Retrospect server with an Airport card installed. Since I'm not currently using Airport from this machine, this workaround has solved my immediate problem, but it is only a workaround. I would also like to see Dantz provide more information on networking or debugging suppport. Disabling the "add by IP address" option is an unnecessary restriction, as others have noted. It would also be nice to have some feedback from Retrospect as to what network ports the application is currently using, and which ports it is listening to for broadcasts. This was a very time consuming problem to debug.
×