Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About crumrine

  • Rank
    Occasional Forum Poster
  1. crumrine

    Retro Linux client crashing

    Best answer I have is restart the Linux client occasionally. While version seven has gotten a little better than 6.5, it still has the same problem - running itself out of allocatable RAM. I was having a problem with this very thing tonight and thought I would check the forums for a resolution. Only saw the same problem. http://forums.dantz.com/ubbthreads/showflat.php?Cat=0&Board=linux&Number=46945&fpart=1&PHPSESSID= Not holding my breath any more for Dantz to resolve this problem. Cheers, Brian
  2. Still leaking memory - retrospect just stops talking after it reaches the end of addressable space (3GB in our case). root 25040 0.0 0.3 3120820 6988 ? S Apr26 4:20 /usr/local/dantz/client/retroclient -daemon Going to turn on my client restarter script again. I will gladly pay for a support incident if that's it takes to get it fixed and get an official bug report filed. Any chance that will help?
  3. I tried the Retrospect 7 client on RHEL 3 and it seemed to be a little better. The Linux client now only locks up after a week or so of usage. Restarting the client is still the safest way for the Linux client to run in our environment. After three weeks of running the 7 client, the server never failed to run out of allocatable memory after 5-6 days. We have been experimenting with the RedHat hugemem kernel for another project. Maybe we can get two weeks out of the client if we run that on these servers. Or we could always upgrade to a 64-bit OS. Brian
  4. crumrine

    7 Client with MS 6.5

    I have upgraded one of our Linux server to use the 7 client (7.0.108) and it works with Retrospect 6.5. I understand that this wouldn't be a supported configuration, but is there anything serious to watch out for? Brian
  5. What we decided to do is restart it before it craps out. We created a special backup job that tells the client to restart - we run this after every backup or the client will continue to allocate memory (heap) to itself every time it's run and finally run out of address space causing it to hang. We added this into the /etc/retroeventhandler script and created a job called "PISTON Client Restart" if [ "$2" = "\"PISTON Client Restart\"" ] && [ "$1" = "EndSource" ]; then /usr/local/dantz/client/retrocpl -stop >>$LOGFILE /usr/local/dantz/client/retroclient -daemon >>$LOGFILE echo "Retrospect Client Restarted" >> $LOGFILE fi This way, at the end of the special backup job, the server is signaled to restart the client. If you don't go this route, you can always issue a "killall retroclient" or "killall -9 retroclient". This has always worked for us in the situations where restarts failed to do the trick. Brian
  6. This is maybe a stupid question, but here goes... Since we have so much trouble with the 6.5 Linux client, is it possible (techically and legally) to run the Retrospect Client 7 on our Linux boxes and continue to use our 6.5 multi-server license to back them up? We backup a lot of Linux servers and don't want to upgrade to the Retrospect 7 server just yet. Thanks, Brian
  7. crumrine

    Terminal Services with 6.5

    OK, I think we have a solution. XP still functions a little differently, but as Glenn stated, one can connect to the console with later versions of Terminal Services. This can be done with Terminal Services Manager or with the command line: mstsc /v:IPaddressORHostName /console where IPaddressORHostName is the IP address or hostname of the server connecting to. The thing that XP allows us to do that we were hoping to replicate in 2003 is the ability for a user to log out and keep Retrospect - and Proactive Backup running. I believe the reason XP performs a little differently is because by default terminal services takes over the console session (we also learned there is a way to tell XP to allow 1 additional session during our research of this). Brian
  8. I am running MultiServer 6.5.350 on an XP machine with great luck using Terminal Services. User sessions can take over Retrospect with no problem - it works great, I am experimenting with this functionality on Windows Server 2000 and 2003 and not getting the same results. I get a message that says "Retrospect is already in use - Another user on this computer is running Retrospect. Only one user at a time can run Retrospect. Select OK to quit Retrospect and run it in this session..." Is there a way to configure Retrospect to work the same way it does on my XP machine - so I can take control of Retrospect with another login? Like on the XP machine, I have a username/password/domain in the Security Settings - "Always run Retrospect as the specified user". I tried turning on "Run Retrospect in the Terminal Services session" (it's turned off on the XP machine) without success. Thoughts? Thanks, Brian
  9. Nate, I have tried to reinstall the Linux client with no success. The same errors are occuring, where the client allocates more and more memory until it reaches some limit and the OS tells it no more, then doesn't answer requests any more. I have had limited success with the client restarting. Would it be possible to get a version of retrospect client written for inetd/xinetd so that it wouldn't sit around taking up more and more memory? When is the next rev of the Linux client scheduled for? Thanks, Brian
  10. With each backup the client allocates more and more RAM and never releases it - of course this is swapped out, but I think eventually the server says you can't have any more and the client doesn't like that so it locks up. Here's what I did to help the problem (still would like a more permanent solution): I created a job named "Client Restart" and had it backup nothing (using the no files selector). At the end of the backup I have the /etc/retroeventhandler script restarting the client. Here's what I used: if [ "$2" = "\"Client Restart\"" ] && [ "$1" = "EndSource" ]; then /usr/local/dantz/client/retrocpl -stop >>$LOGFILE /usr/local/dantz/client/retroclient -daemon >>$LOGFILE echo "Retrospect Client Restarted" >> $LOGFILE fi I scheduled this job before each backup - I imagine that we will need to do this after the backup jobs if the problem comes up again. So far we have been not had the client lock up since turning this on. Note: I started this exercise by trying to do this after every source - this didn't work as it treats each volume/subvolume as a separate source and if the client exits while a backup is running it doesn't want to restart while the job is running. Unless you are only backing up one volume/subvolume, I wouldn't recommend this unless you code for a specific volume/subvolume order.
  11. This has turning into kind of a daily ritual for us. We get about 1 day of the client running before we have to kill and restart it. Any ideas what might be happening with it? Anything I can try?
  12. Another interesting (possibly related) symptom of this is that when retroclient chews up all the memory, the service stops responding to the "service" command. "service rcl stop" does not respond - the only way I have found to get the client in an operating state again is to kill it - then start again with "service rcl start".
  13. I have been monitoring some problems we are having running the RS linux client on RHEL ES Update 3. It seems to be eating up (virtual) memory like a champ. Very frequently we get out of memory errors (SThreadSpawn: pthread_create() failed with error 12) in the log file. I ran a 'ps avxww | grep retro' and noticed that the retrospect process has a lot of memory (virtual) allotcated to is (could this be why it's exiting with the out of memory error?). Here's the output of command on a couple machines we are having a problem with (after running one backup): machine 1 (570MB allocated): 1419 ? S 0:38 8 152 569055 1696 0.1 /usr/local/dantz/client/retroclient -daemon machine 2 (1.5GB allocated): 2157 ? S 0:06 7 152 1562719 3884 0.1 /usr/local/dantz/client/retroclient -daemon Of course it's not really using that amount of memory, but could that be the reason why it thinks it runs out of memory. Maybe it's not freeing the memory up properly after using it? Upon initial startup of the retrospect client the memory usage is more reasonable: machine 1 (45MB allocated): 26229 ? S 0:00 7 152 45587 892 0.0 /usr/local/dantz/client/retroclient -daemon machine 2 (45MB allocated): 29319 ? S 0:00 6 152 45579 880 0.0 /usr/local/dantz/client/retroclient -daemon Maybe retrospect's client needs to be restarted after every backup??? Does anyone else have this running solidly in a RHEL environment? Thanks, Brian
  14. We have a multi-server 6.5 installation and are looking fro a little more horsepower from the backup - chews up our Athlon 500 using three execution units . We have a dual-CPU Compaq server around that could be used as a new backup server (Dual 600 P3, 1 GB RAM, etc). I have seen applications run mutli-threaded inside the program, but appeared as a single process to the OS, thus gaining nothing from having the second CPU. Does 6.5 Multi-server take advantage of the extra CPU, or does it depend on the OS to make use of the other processor? Or would I be better off just using a old desktop computer (1Ghz P3) to run the server? Any help would be appreciated. Thanks, Brian
  15. I recently upgraded from 6.0 to 6.5 Multi-server. I really like the idea of having multiple backups running simultaneously, but am having a bit of a reporting problem. I use retroeventhandler.bat to report on the status of our backups. What's happening is that it's mixing the jobs in the report emails if they are running concurrently. Is there a way to separate the job notification email by execution unit? Or do I have to give up on my new simultaneous executions in order to get good reports? Is it possible that the retroeventhandler.bat was updated to support multiple jobs and the update was not installed on the computer during the upgrade? What are people doing when they need to start and stop services - that seems even riskier than my reporting problem? I saw the email notifications section in Preferences - that appears to only cover problem notification. There does not appear to be anything in the online help (too lazy to go get the manual) that explains exactly what this is for. Brian