Jump to content

Recommended Posts

Dave,

 

 

 

OSX server not OSX workstation (and yes I know they are basically the same -- however you keep trying to point that there is some problem with our network or the topology and there is NOT)

 

 

 

You have not duplicated the problem. We can run an immediate backup, but the scheduled backups are comming across this problem (in a script). And who know what your pause may or might not do to retrospect during the copy/compare process. What version OS are you running the Retro server on? we are using an old G3 - OS 9.2.

 

 

 

This does not happen to ANY other client on our network, including OSX clients on workstations. As for topology, we are all in the same subnet and linked via the same switches.. (and no moving it around on the switch makes no difference)

 

 

 

Again, the ONLY thing having provlems is retrospect, not SAMBA, AFP, TCP/IP or AppleTalk or any other protocol is having a problem and we move literally gigs per day around from workstation to workstation and to and from the server with never a problem. Retrospect 4.3 - never a problem with the beta client for OSX.

 

 

 

Maybe we can some day try a cross over cable, but this is a 24 hour a day mission ciritical server, we can't just take it down on a whim to prove what we are 99% sure is a retrospect problem. (The client is NOT releasing properly, if we get no errors suchs as -43 or whatever the OSX server backs up with no problem (however there is almost always atleast one -43 error.)

Link to comment
Share on other sites

Finally!!! Thank you we will be waiting.. paitently is not assured though :)

 

 

 

but thanks for the response finally -- atleast we are not going crazy !!

Link to comment
Share on other sites

In reply to:

the ONLY thing having provlems is retrospect, not SAMBA, AFP, TCP/IP or AppleTalk or any other protocol is having a problem and we move literally gigs per day around from workstation to workstation and to and from the server with never a problem


 

 

 

Adam Angst wrote the following in his reveiw of Retorspect for TidBITS a couple of months ago:

 

http://www.tidbits.com/tb-issues/TidBITS-624.html

 

"...years of using Retrospect have taught me that it's often an electronic canary in the digital mines. For those unfamiliar with the analogy, miners used to bring a canary down into the mine shaft as an early warning system - if noxious gases caused the canary to keel over, the miners knew to get out. Because of its need to operate at the highest possible speeds with unusual storage devices, all without losing a single bit of data, it's not unusual to see Retrospect throw an error when everything else appears to work fine. A friend once told me of a story about a large company that upgraded a Cisco router to new firmware containing a bug which lost one packet in a million. The bug went unnoticed until Retrospect started reporting errors, because although one packet in a million doesn't sound like much, it adds up to a real problem when you're backing up gigabytes of data."

 

 

 

(end of quote)

 

 

 

Now, I agree that there appears to be some awful problem with the OS X Client that your installation is experiencing. But the 'pitond protocol violations' are a almost certainly a router or NIC thing. And to begin your troubleshooting with the contention of "I know it is not possible that our network hardware is less then perfect" is limiting your options for solutions.

 

 

 

You might consider launching pitond from a shell session, and leave the session open to see if you get any message back. Or, you could turn up logging for pitond and see if it gives any useful information. Navigate to /Applications/Retrospect Client/Retrospect Client.app/Contents/Resources and type:

 

./pitond --help

 

for instructions on logging.

 

 

 

Dave

 

 

 

 

 

 

Link to comment
Share on other sites

Dave,

 

 

 

Thanks for the info.. or what you seem to think we have done here. But honestly, we would not be posting here if we were not 99% sure that the problems is with Retrospect and not our network. We have tested to make sure that it was not something on our end. And as Irene has posted this is a problem they are aware of, so we will sit and wait for some future update so that we can properly back up the OSX server machine.

 

 

 

ps. I realize that many users in this forum are green around the gills. We have done everything possible to make sure that this problem was not network/system caused.

Link to comment
Share on other sites

In reply to:

You have not duplicated the problem


 

Well, that's the point, isn't it?

 

 

 

>>We can run an immediate backup, but the scheduled backups are comming across this problem (in a script)<<

 

 

 

Well, that's the first time _that_ information has been shared! Your previous posts specifically said:

 

 

 

 

 

>>Max OSX (G4) as a file server <--errors everytime from 216, 505, 515>>

 

 

 

>>anytime there is ANY error, including a -43, on the OSX client, the client is automatically "not released"

 

 

 

Are you saying that you _never_ get any errors on Immediate Backups, but you _always_ get errors on Scripted Backups?

 

 

 

For example, if you run an Immediate Backup on one of the defined subvolumes and get no error, can you then turn around and run a Scripted Backup (from the Run menu) and see the problem?

 

 

 

It's obvious that most people are not seeing the problem. Nothing would help Dantz more then to have the people who _are_ seeing this list the exact steps it takes for them to reproduce the problem.

 

 

 

>>We have done everything possible to make sure that this problem was not network/system caused<<

 

 

 

You can understand my distrust of this statement since you have not shared with the Forum any of the things you have done. For example, since the problem happens on only one machine (which is running a slightly different version of Mac OS X, but that might easily be a red herring) have you swapped out the NIC?

 

 

 

99% leaves 1 out of a hundred. With those odds, I wouldn't just wait for a new release...

 

 

 

Dave

Link to comment
Share on other sites

Because we didn't post everything we tried you don't trust us? Sorry we barely have time to get buggy software working let alone post everything we tried step by step. Its dantz job to fix their software not ours. We are not beta testers.

 

 

 

part of the problem for making a forum be your #1 form of tech support is that things get misunderstood, what I said meant was :

 

 

 

You have not duplicated the problem : === Since you are so quick to point out the difference in network topology, hardware, nic cards and other things... Including what OS you are using, what OS the server is installed on, what client is not backing up etc, your test at face vaule proves nothing other than the fact you have not DUPLICATED our setup.

 

 

 

 

 

again.. thanks for your help.. we are waiting on dantz.

Link to comment
Share on other sites

We are now experiencing this problem with one of our clients.

 

 

 

Workgroup Server 5 running on OS X Server 10.1.4., G4 dual ghz Quicksilver 2gb ram. Client machine is a 700mhz AGP G4 running 10.1.4.

 

 

 

I successfully backed up the machine on 6/4/02. Last night retro returned the 505 error. Client software shows status as "in use by 'root' for '2'" on the problem machine. The reference of 2 is the name of a specific storageset/tape. Server has been rebooted and the client software has been restarted. I also tried going into client configuration, forgetting the problem client and reimporting him into retro. I get the 505 error after I enter the password. He currently remains unlogged.

 

 

 

Any ideas? The next thing I was thinking of doing was uninstalling the client application and reinstalling. the only other thing I can think of mentioning is that the client app is set as a startup item in the login window. This has been the case for awhile, however.

 

 

 

Everything was working fine for quite awhile. I achieved numerous successful sessions with this machine until this started happening.

 

 

 

thanks.

 

 

Link to comment
Share on other sites

In reply to:

Last night retro returned the 505 error. Client software shows status as "in use by 'root' for '2'" on the problem machine. The reference of 2 is the name of a specific storageset/tape. Server has been rebooted and the client software has been restarted


 

Launching and quitting the OS X Client application has no effect on the unix process that is the actual client software. You can "kill" the unix process (named 'pitond') by holding the Apple key and pressing the "off" button in the Client application window, or if you're comfortable with the Terminal you can kill the process from there.

 

 

 

Note the text in the "Status" area of the OS X Client application. When you press Command+Off, the Status should read "Not running." When you then click the "on" button, the Status should read "Ready."

 

 

 

Dave

Link to comment
Share on other sites

Thanks, I'll keep that handy. I ended up doing a fsck -y on the client machine and that cleared up the problem. Successful back up last night. What I'm still not clear of is how the problem was created in the first place. Still new to UNIX concepts. Thanks again.

Link to comment
Share on other sites

In reply to:

The only way to clear this problem is to reboot. You can kill the pitond process and restart it and you still get the same 505 error


 

 

 

Troll,

 

 

 

At the risk of alienating you further, I just have to ask:

 

 

 

1- If you kill pitond from the Terminal, what does the Status field of the OS X Client application show?

 

2- When you click the "on" button in the OS X Client application, what does the status window show?

 

 

 

Please respond. The idea that after killing a unix process it is not fresh when relaunched rocks my faith in the forces of nature. I was looking forward to tonight's sunset!

 

 

 

Dave

 

----

Link to comment
Share on other sites

Dave,

 

 

 

You will see the sunset... troll's have no control over that. :)

 

 

 

 

 

*trying to recall because it was a couple weeks ago. The status was : Turned off

 

and then when you click it on it says : Ready however as soon as it goes to back up it switches to "in use by...."

 

 

 

505 error on the server

 

 

Link to comment
Share on other sites

In reply to:

*trying to recall because it was a couple weeks ago. The status was : Turned off

 

and then when you click it on it says : Ready however as soon as it goes to back up it switches to "in use by...."


 

If you kill pitond the Status field will not read "Turned off."

 

When the process is not running, the Status field in the application (which is just a window on the process) will read "Not running."

 

 

 

Clicking the "off" button is not killing pitond. Just as with the old OS 9 control panel where clicking "off" did not unload the extension from the Macintosh's memory, the "off" button keeps the pitond process alive but configures the machine not to be a backup client.

 

 

 

You can kill pitond from the OS X Client application by holding the Command (Apple) key while clicking the "off" button (or use the Terminal if you know how).

 

 

 

Furthermore, before attempting a backup, you should visit Configure->Clients and see if the client responds properly in either the' Backup Client Database' window or in the 'Backup Clients on Network' window.

 

 

 

I have no idea what might have caused the pitond to stay in an "in use" state; I have never seen it on many OS X clients (both OS X Server and OS X). But if you didn't actually kill the unix process, then you didn't give the process a chance to start fresh.

 

 

 

And that explains the beautiful, late summer sunsets I enjoyed last week.

 

 

 

Dave

Link to comment
Share on other sites

Dave,

 

 

 

yeah we killed all processes including pitond.. and retros.22 or whatever.. Like I said it has been a couple weeks and the status was turned off ( I am not sure what it would say if we just killed the pitond because we were killing everything in the terminal window (holding the command and turning it off locks it up).

 

 

 

I just saw Irene post to another user in another thread.. this is an issue they are aware of and they are working on it.. truly all we have time for now is to wait. We are backing up bymounting the server volumes on the desktop of the os9.2 machine. we obviously are not backing up things like permissions etc etc but its better than nothing until Dantz can fix this problem.

 

 

 

 

 

 

Link to comment
Share on other sites

  • 4 weeks later...

Is there any progress on this problem yet? We have had this software for almost 2 months now and are unable to use it properly!

 

 

 

 

Link to comment
Share on other sites

>>>>There have not been any updates released to address this. Dantz is looking into this problem.

 

 

 

Thanks,

 

 

 

Irena Solomon

 

Dantz Tech Support>>>

 

 

 

Irena,

 

 

 

I want to start by saying that this is not directed at you personally or anyone there for that matter. I guess I just don't understand (and I think quite a few users feel this way) how dantz can call this an official release, charge top dollar and then offer no techinical support. I am sure that you see that this thread started over a month ago, and your post to me that dantz was looking into this problem was 6-05-02. This is mission critical software. Its not an mp3 player or cd burning software that can easily be replaced or work arounds implemented. Most of us IT/IS Professionals rest our jobs on the ability to backup data and then quickly restore it.. I think its pretty sad that we cannot rely on retrospect to do this. I hardly doubt that if someone wanted to purchase this and they said "sorry don't have the money now, but we will work on it" that Dantz would give them the software for free.. yet Dantz expects us to do the exact same thing.. we have given Dantz our time (even beta tested and submitted bug reports) and our money, give us a product that reliably works with OSX!

Link to comment
Share on other sites

I just want to explain my fustration on the whole situation. I am also receiving the same errors and having to kill the process and restart them is fustrating. I am also getting an additional problem. Recently the piton process spun out of control on our mail server utilizing half of the processor's resourses until we were able to kill the process and restart it. We have our mail server on a new dual processor xserve . Our concern is that if the piton process spins out of control and consumes half of the processor's resourses again, this will severely limit our efficiency . Has anyone else had the same problem I have where the piton process is effecting the system itself? If not Retrospect can you please help?

 

 

 

 

Link to comment
Share on other sites

>>> Recently the piton process spun out of control on our mail server utilizing half of the processor's resourses until we were able to kill the process and restart it. We have our mail server on a new dual processor xserve . Our concern is that if the piton process spins out of control and consumes half of the processor's resourses again, this will severely limit our efficiency . Has anyone else had the same problem I have where the piton process is effecting the system itself? If not Retrospect can you please help? >>>

 

 

 

We have had that same problem, the only way to kill it seems to be to login through the terminal and kill the process ID. Other than that... Cannot really help you with that problem, cause we have not solved that one either... we can only hope for another client/server update from dantz I am afraid.

 

 

 

 

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...