Maser Posted January 10, 2003 Report Share Posted January 10, 2003 This has happened twice and I've asked the remote users, so I'm assuming I can duplicate this bug if I tried this. Backup server computer: G4/533 384M RAM 10.2.3 only -- no other software installed apart from what comes in Apple's Software Update Adaptec 21960 SCSI card with the supported new 1.2 drivers. Backup clients: Laptops running Windows XP with the current 6.0 Client. REPRODUCABLE PROBLEM (and I've seen it twice since starting a new backup set): Backup server will start backing up remote windows client (large number of gigs of data). Backup will hum along as expected. *USER* will turn off the laptop using the "shutdown" option from the Start Menu while backup is still going on. Retrospect -- the program -- will die. No error message, no nothing. Nothing in the log file about it either. Just back to the Finder. What probably *should* be happening is that Retrospect should notice that the client is "off-line", but some "kill" signal is being sent by the client. Catalogs must then be "repaired" before they can be appended. This may not be limited to *laptops* as I've seen this behavior before, but not been able to actually watch this happening. I saw this unexpected quit actually happen while I happened to be watching the monitor the first time. It then happened to a 2nd laptop (same exact behavior by the "client") immediately after (this was near 5:00 when laptop users would normally shut their laptops down to take them home). The OSX machine was rebooted between the "quits" It's happened a noticable number of times -- but only on my Windows backup servers -- never on my Mac servers. (I run 4 different backup server computers -- all exactly as described above. 3 of them back up only Windows machines, 1 does only Macs.) Anybody else seeing this? Known issue? If so, is there a workaround? (ie, more RAM for the backup computers?) This is a killer. Link to comment Share on other sites More sharing options...
Maser Posted January 10, 2003 Author Report Share Posted January 10, 2003 More data from shutting down other operating systems: OSX -- a normal shutdown of the client just "closed" the backup as expected. WinME -- also with the 6.0.110 client -- same as OSX. Win2000 -- with same client -- CRASH OF RETROSPECT. We're trying to figure out if we have any NT machines as well to try this with. Is the problem Retrospect? The 6.0.110 client? Is the 6.0.110 client for Windows the latest client? Link to comment Share on other sites More sharing options...
Maser Posted January 10, 2003 Author Report Share Posted January 10, 2003 HAH!!! this *does seem to be* a Windows client problem! We had an NT4 machine still with a "5.6" version of the client (which had been upgraded through pushing the 6.0 client updates through the network, but the NT machine had never rebooted.) We started a backup of the system through "backup server" while it was running the 5.6 client. We had the remote client user shut down the computer while we watched. The backup server "closed" this client shut down as expected. We then had the user restart the computer. This was now running with the "6.0.110" client. Backup was restarted. user shut down the computer exactly the same way. Retrospect died. this is extremely reproducable here!!! Is there a later Windows client than "6.0.110" we should be using???? Link to comment Share on other sites More sharing options...
CallMeDave Posted January 10, 2003 Report Share Posted January 10, 2003 In reply to: We had an NT4 machine still with a "5.6" version of the client (which had been upgraded through pushing the 6.0 client updates through the network, but the NT machine had never rebooted.) Were the other machines also updated from 5.6 to 6.0.110? I just tried it on an XP laptop that has 6.0.110 installed (but not an update) and Retrospect had no problem when we shut the laptop down in the middle of the backup. Retrospect reported execution incomplete with an "Access terminated" error. We tried both a Backup Server script and an Immediate Backup. Have you tried uninstalling and reinstalling the client on one of these machines? Dave Link to comment Share on other sites More sharing options...
Maser Posted January 13, 2003 Author Report Share Posted January 13, 2003 All machines tested were upgraded using the Windows client upgrader pushed from within Retrospect and the machines reboot themselves (if necessary). We'll have to test this with something that was "clean installed" to confirm this. - Steve Link to comment Share on other sites More sharing options...
Maser Posted January 14, 2003 Author Report Share Posted January 14, 2003 Further testing: "clean install" windows 6.0 clients do *NOT* crash Retrospect on OSX "pushed upgraded clients"? That's what's causing the crash. Can somebody try to replicate it? It's really not feasible for us to visit 150+ computers, uninstall and reinstall retrospect and then remove/readd the computers to the backup server scripts. Or can somebody let me know if there's a new Windows client updater coming "soon" that we can "push" that will correct this? Link to comment Share on other sites More sharing options...
AmyJ Posted January 20, 2003 Report Share Posted January 20, 2003 Hi Steve - We tried reproducing this in house and were unable using the same steps outlined in your posts. Have you been able to confirm on any other clients that a manual upgrade resolves the problem you're seeing? Link to comment Share on other sites More sharing options...
Maser Posted January 21, 2003 Author Report Share Posted January 21, 2003 To *effectively* reproduce these steps, you'd have to start with whatever version of Mac OSX was out was out when the *first* Retrospect for OSX was released (March 2002). That came with the 6.0 Windows client updater and that's what we "pushed" out to overwrite the 6.0 clients. That's the only thing that would be difficult to effectively reproduce as a setup. We've been seeing if we can reproduce this on *clean* installs of the client. We can't. That works as expected. it's only the upgraded-by-pushing-the-upgrade-from-Windows-5.6-to-6.0 from on OSX that is consistently crashing Retrospect. Honest! Will there be another windows client updater (6.1 or something)? We can't "repush" the 6.0 client updater because it won't overwrite what already exists. Link to comment Share on other sites More sharing options...
Maser Posted January 21, 2003 Author Report Share Posted January 21, 2003 Data point: On the NT machine I referenced above (was 5.6 pushed to 6.0 where 5.6 could shut down without killing Retrospect, but 6.0 couldn't). I *just now* had the user "repair" the 6.0 client install (by running the setup.exe manually -- not a push). Client rebooted. Started a backup of the client. Client shut down in the middle of the backup. Retrospect dies. If it helps, I can post the contents of the Retrospect Crash log. Many of these older clients were probably "push" upgraded from many versions of the Windows client -- probably even starting from pre-5.6 client upgrades pushed from Retrospect 4.3. Something, somewhere, went wrong with the "push" Windows client upgrade that, unfortunately, a "repair" doesn't fix... What can I do to help reproduce this on your end? Link to comment Share on other sites More sharing options...
Maser Posted January 27, 2003 Author Report Share Posted January 27, 2003 Now that you've had Q/A duplicate this, is there a workaround short of uninstalling/reinstalling the client everywhere? Revert to 5.0.205? Get a 6.0.111 (or later) new client RDU and push that? Anything? Link to comment Share on other sites More sharing options...
AmyJ Posted January 27, 2003 Report Share Posted January 27, 2003 There are no current workarounds outside of clean installing the client software. Our developers are aware of the issue and are investigating. We don't know at this time when a fix will be available. Link to comment Share on other sites More sharing options...
elleffemm Posted January 31, 2003 Report Share Posted January 31, 2003 More confused than ever because this is a Mac problem and the thread, re a MAc problem, seems to have become a thread about an NT problem. When Retro Express 5.0.238 in OSX 10.2.3 opens, it seems to run OK but also, immediately, opens a Console crash log. Why? Link to comment Share on other sites More sharing options...
Maser Posted January 31, 2003 Author Report Share Posted January 31, 2003 It's a "mac" problem because it crashes the Mac Retrospect OSX app (and, hopefully will be fixed in the near future now that Dantz Q/A replicated the behavior) Or it's a "windows client" problem because only some of the "pushed" upgrades are affecting some Windows clients (maybe all -- we aren't sure.) Would this happen on the Windows version of the app? Who knows... We can't try that here. Link to comment Share on other sites More sharing options...
Maser Posted February 14, 2003 Author Report Share Posted February 14, 2003 10.2.4 does *NOT* fix this problem. Unfortunately. Any ETA for a bug fix? Weeks? Months? Years? It appears to be happening to *clean install* Win XP machines now, on occasion, too... Link to comment Share on other sites More sharing options...
AmyJ Posted February 14, 2003 Report Share Posted February 14, 2003 We don't have an ETA on this. We'll post information when it becomes available. Thank you for your continued patience and thank you for helping track down the issue. Link to comment Share on other sites More sharing options...
Maser Posted March 10, 2003 Author Report Share Posted March 10, 2003 I've lost yet *another* weekend of backups to two sets of backup machines because of this bug (where the user being backed up shut his computer down at 5:00 p.m., thus "killing" the backup.) When will this bug be addressed? It's not a "clean client install" vs. a "push client upgrade" issue any longer. It costing my unit time, money *and* security! Link to comment Share on other sites More sharing options...
CallMeDave Posted March 10, 2003 Report Share Posted March 10, 2003 Quote: It's not a "clean client install" vs. a "push client upgrade" issue any longer. What do you mean? Previously you said the only way you saw it was with a 'push' Client upgrade... Dave Link to comment Share on other sites More sharing options...
Maser Posted March 10, 2003 Author Report Share Posted March 10, 2003 3 posts above this one, I indicated we are now seeing this with "clean install" clients as well. That's what's frustrating: It's extremely reproducable with "push" clients. But it's only "occasionally" reproducable with clean install clients. Since I don't know what causes the crash, I can't figure out exactly what clean clients are doing here. It's costing us "security" to lose two days of backup out of seven (meaning the weekend) and frequent evenings when it crashes. - Steve Link to comment Share on other sites More sharing options...
Maser Posted March 14, 2003 Author Report Share Posted March 14, 2003 I *guarantee* this is now happening with *clean install* clients (running Windows XP) It happened to *two* of my backup servers last night! AAAHHH! Where's the fix? Link to comment Share on other sites More sharing options...
AmyJ Posted March 18, 2003 Report Share Posted March 18, 2003 Quote: I *just now* had the user "repair" the 6.0 client install (by running the setup.exe manually -- not a push). This is not a clean install. A clean install is to uninstall the client, reboot and install a new copy. In the meantime, you may want to try setting your backups to run later at night when users are less likely to be shutting their machines down during backup. If these are laptop users who take their machines home, try scheduling them to be backed up earlier in the day rather then later. We have no time frame as to when this will be fixed. The best solution at this time would be to clean install the client on the machines that are most likely to shut down during a backup (laptop users). Link to comment Share on other sites More sharing options...
Maser Posted March 19, 2003 Author Report Share Posted March 19, 2003 "clean installs" are also crashing -- this is why this needs to be seriously addressed by Dantz ASAP. It's moved beyond the "push-upgraded" clients causing this problem. We have an XP "load" that we push to all new computers using Ghost. The load has a *clean* install (not an upgrade by either manual or "push") of the Retrospect 6 client. These clients are *also* causing Retrospect to crash when the clients shut down -- occasionally. Even these "loaded" clients that remove, reboot and reinstall the Windows 6 client software still cause the problem. We have not been able to determine what the *exact* issue is (ie, is it that the client shuts down in the middle of backing up a "large" file and the program can't handle it?) because we can't reproduce it consistently. But it's clear it's moved beyond the original "push upgraded on NT4 client". But uninstalling, rebooting, and reinstalling 6.0 Windows client is not -- repeat *NOT* -- fixing the problem here. I've reformatted my backup machines with a "clean" 10.2.4 system. Boosted the RAM on them from 384M to 896M, etc. The problem continues. The program is panicking for some reason when these clients shut down. Honest. Backup software should "just run" -- it shouldn't require constant observation to make sure it's "up". Link to comment Share on other sites More sharing options...
Mayoff Posted March 19, 2003 Report Share Posted March 19, 2003 Does the backup computer crash when running under OS 9 and a windows user restarts? What is the specific symptom of this more recent crash? What do you see on screen when this happens? Does Retrospect get an assert error or does Retrospect just freeze? Does OS X get a panic screen? If you do get a Panic, what is displayed in the Panic, it may be helpful toward identifying the problem. How do you know this panic is related to a sudden client shutdown/restart? Understanding how you identified this as the cause will help us identify why it is happening. Link to comment Share on other sites More sharing options...
Maser Posted March 19, 2003 Author Report Share Posted March 19, 2003 > Does the backup computer crash when running under OS 9 and a windows user restarts? I don't have a way of testing this. I don't have Retrospect running anything under OS 9 (as I need to back up OSX machines with the same setup) >What is the specific symptom of this more recent crash? What do you see on screen when this happens? Does Retrospect get an assert error or does Retrospect just freeze? Does OS X get a panic screen? If you do get a Panic, what is displayed in the Panic, it may be helpful toward identifying the problem. Retrospect -- the whole program -- quits. There is no error on the screen, there is no "panic" screen. There is no notification at all. There's nothing in the Retrospect log file to indicate an action (written to the log) prior to the quit. Restarting Retrospect gives the prompt that there was an unexpected shutdown and I have to repair the catalog. A "Retrospect.crash.log" file will be generated in /library/logs/crashreporter that looks like this: Date/Time: 2003-03-17 12:53:22 -0500 OS Version: 10.2.4 (Build 6I32) Host: <mycomputer>.engin.umich.edu Command: Retrospect PID: 376 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000030 Thread 0 Crashed: #0 0x905115d8 in RecvData #1 0x905130bc in OTRcv #2 0x0036f7a0 in 0x36f7a0 #3 0x003700f0 in 0x3700f0 #4 0x003701b8 in 0x3701b8 #5 0x00372f74 in 0x372f74 #6 0x00388ff0 in 0x388ff0 #7 0x001d23d4 in 0x1d23d4 #8 0x003003d0 in 0x3003d0 #9 0x001d23d4 in 0x1d23d4 #10 0x01e8f2a0 in 0x1e8f2a0 #11 0x001f7e04 in 0x1f7e04 #12 0x001d24e8 in 0x1d24e8 #13 0x001f8084 in 0x1f8084 #14 0x01e8fc3c in 0x1e8fc3c #15 0x001f7e04 in 0x1f7e04 #16 0x001d24e8 in 0x1d24e8 #17 0x001f8084 in 0x1f8084 #18 0x01e901f8 in 0x1e901f8 #19 0x001d23d4 in 0x1d23d4 #20 0x0026e31c in 0x26e31c #21 0x001d23d4 in 0x1d23d4 #22 0x00275634 in 0x275634 #23 0x001f7e04 in 0x1f7e04 #24 0x001f8000 in 0x1f8000 #25 0x0027571c in 0x27571c #26 0x001f7e04 in 0x1f7e04 #27 0x001f8000 in 0x1f8000 #28 0x00273160 in 0x273160 #29 0x001d23d4 in 0x1d23d4 #30 0x00275634 in 0x275634 #31 0x001f7e04 in 0x1f7e04 #32 0x001f8000 in 0x1f8000 #33 0x001f7e04 in 0x1f7e04 #34 0x001f8000 in 0x1f8000 #35 0x002756f8 in 0x2756f8 #36 0x001f7e04 in 0x1f7e04 #37 0x001f8000 in 0x1f8000 #38 0x001cbcc0 in 0x1cbcc0 #39 0x001f7e04 in 0x1f7e04 #40 0x001f8000 in 0x1f8000 #41 0x001cbdb8 in 0x1cbdb8 #42 0x001cbf04 in 0x1cbf04 Thread 1: #0 0x9000514c in syscall #1 0x90515d6c in BSD_waitevent #2 0x9051573c in CarbonSelectThreadFunc #3 0x90020d48 in _pthread_body Thread 2: #0 0x9003eaa8 in semaphore_wait_signal_trap #1 0x9003e8c4 in _pthread_cond_wait #2 0x9051dc30 in CarbonOperationThreadFunc #3 0x90020d48 in _pthread_body Thread 3: #0 0x90073c48 in mach_msg_trap #1 0x90005f90 in mach_msg #2 0x90148b10 in __CFRunLoopRun #3 0x90180fe4 in CFRunLoopRunSpecific #4 0x0059388c in thTop (thread.c:100) #5 0x90020d48 in _pthread_body Thread 4: #0 0x90073c48 in mach_msg_trap #1 0x90005f90 in mach_msg #2 0x90148b10 in __CFRunLoopRun #3 0x90180fe4 in CFRunLoopRunSpecific #4 0x94d9c1c0 in _ZN10HALRunLoop9OwnThreadEPv #5 0x94d911b0 in _ZN9CAPThread5EntryEPS_ #6 0x90020d48 in _pthread_body PPC Thread State: srr0: 0x905115d8 srr1: 0x0200f030 vrsave: 0x00000000 xer: 0x20000000 lr: 0x905115c8 ctr: 0x90513080 mq: 0x00000000 r0: 0x905130bc r1: 0xbfffc1b0 r2: 0x24004282 r3: 0x00000000 r4: 0x00000036 r5: 0x0205a316 r6: 0x0000bcea r7: 0xbfffc390 r8: 0x00000000 r9: 0x00000000 r10: 0x0000d28d r11: 0x0000a8e0 r12: 0xa0512574 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x0205a316 r18: 0x00000000 r19: 0x00000000 r20: 0xbffffe44 r21: 0xffffffff r22: 0xbffffc00 r23: 0xffffc8f6 r24: 0x00000000 r25: 0xbfffcdc0 r26: 0xbfffc44c r27: 0x0000bcea r28: 0x00000316 r29: 0xbfffc448 r30: 0xbfffc3e8 r31: 0x905115c8 > How do you know this panic is related to a sudden client shutdown/restart? Understanding how you identified this as the cause will help us identify why it is happening I would come in in the morning with the program quit. I checked the log to see who was getting backed up during the quit. I call them and ask them what they (the client) did at that time. They say "I shut my computer down from the "Start" menu" -- as opposed to just putting the computer to sleep or unplugging the network cable. One time when this happened during the day (when I noticed it), I immediately called the user who was getting backed up and confirmed his actions. I had him *do it again* while I watched the backup server program. His computer (with clean install 6.0 client) was getting backed up. He shut it down while I was on the phone with him and I watched Retrospect die in front of my eyes. Twice! Really. I'm not making this up. What more can I get you to get a quick resolution to this problem? Link to comment Share on other sites More sharing options...
Maser Posted March 19, 2003 Author Report Share Posted March 19, 2003 And -- just to clarify (again) -- I have 3 backup servers backing up Windows NT/2000/XP clients. *All three* show this problem. there seems not to be a problem if Mac clients or Win98/ME clients do the same thing. It's specific with something sent (?) from Win NT/2000/XP clients. Or something about using a supported Adaptec 29160 card (current drivers?) with a Quantum DLT 8000 drive. Unfortunately, I have no other SCSI cards to test with this. Apparently, Dantz Q/A *has* reproduced this problem. That's what's frustrating. "You" can see the problem, but there's still no fix for something I brought to your attention over 2 months ago now. Link to comment Share on other sites More sharing options...
Mayoff Posted March 19, 2003 Report Share Posted March 19, 2003 Quote: I don't have a way of testing this. I don't have Retrospect running anything under OS 9 (as I need to back up OSX machines with the same setup) Actually, you can use Retrospect under OS 9 to back up any Client running OS X. You just can't back up OS X on a local dual boot system if you are booted under 9 Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.