Re: [COOT] Failure to mount /home/emsley delays coot startup
On 06/23/10 13:47, Ben Eisenbraun wrote: > On Wed, Jun 23, 2010 at 06:03:22PM +0100, Paul Emsley wrote: >> On 23/06/10 13:26, Schubert, Carsten [PRDUS] wrote: >>> Is there any way to get rid of these references in the pre-compiled >>> binaries? >> >> Not that I know of (other than by editing). > > You can use chrpath (if it's the rpath that is causing the problem). > > $ chrpath -l /programs/i386-linux/coot/0.6.2-pre-1-r2969/bin/coot-real > /programs/i386-linux/coot/0.6.2-pre-1-r2969/bin/coot-real: > RPATH=/lmb/wear/emsley/autobuild/Linux-cycle-pre-release-gtk2-python/lib > > http://directory.fsf.org/project/chrpath/ Even though not necessary in this case, I've found PatchELF (http://nixos.org/patchelf.html) to be a useful alternative to chrpath on Linux. PatchELF allows you to grow the paths as well, and it is (as far as I know) still supported. // Cheers; Johan -- Postdoctoral Researcher @ Otwinowski Lab __ UT Southwestern Medical Center * 5323 Harry Hines Blvd. * Dallas TX 75390-8816 * +1-(214)-645-6378 * http://bones.swmed.edu
Re: [COOT] Failure to mount /home/emsley delays coot startup
Ben, thanks for the suggestion, we'll give that a shot. Carsten > -Original Message- > From: Mailing list for users of COOT Crystallographic Software > [mailto:c...@jiscmail.ac.uk] On Behalf Of Ben Eisenbraun > Sent: Wednesday, June 23, 2010 2:47 PM > To: COOT@JISCMAIL.AC.UK > Subject: Re: [COOT] Failure to mount /home/emsley delays coot startup > > On Wed, Jun 23, 2010 at 06:03:22PM +0100, Paul Emsley wrote: > > On 23/06/10 13:26, Schubert, Carsten [PRDUS] wrote: > > >Is there any way to get rid of these references in the pre-compiled > > >binaries? > > > > Not that I know of (other than by editing). > > You can use chrpath (if it's the rpath that is causing the problem). > > $ chrpath -l /programs/i386-linux/coot/0.6.2-pre-1-r2969/bin/coot-real > /programs/i386-linux/coot/0.6.2-pre-1-r2969/bin/coot-real: > RPATH=/lmb/wear/emsley/autobuild/Linux-cycle-pre-release-gtk2- > python/lib > > http://directory.fsf.org/project/chrpath/ > > -b > > -- > | Ben Eisenbraun | Software Sysadmin > | > | Structural Biology Grid | http://sbgrid.org > | > | Harvard Medical School | http://hms.harvard.edu > |
Re: [COOT] Failure to mount /home/emsley delays coot startup
Paul Emsley wrote: It may help if I made SuSe-specific binaries - one day I'll get a SuSe box (or virtual machine). Or you could build the binaries yourself. Paul. If anyone has any luck with this tell me. I've tried building SuSe binaries on a couple of occasions - in real machines and VMs - without luck. -- EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm
Re: [COOT] Failure to mount /home/emsley delays coot startup
On Wed, Jun 23, 2010 at 06:03:22PM +0100, Paul Emsley wrote: > On 23/06/10 13:26, Schubert, Carsten [PRDUS] wrote: > >Is there any way to get rid of these references in the pre-compiled > >binaries? > > Not that I know of (other than by editing). You can use chrpath (if it's the rpath that is causing the problem). $ chrpath -l /programs/i386-linux/coot/0.6.2-pre-1-r2969/bin/coot-real /programs/i386-linux/coot/0.6.2-pre-1-r2969/bin/coot-real: RPATH=/lmb/wear/emsley/autobuild/Linux-cycle-pre-release-gtk2-python/lib http://directory.fsf.org/project/chrpath/ -b -- | Ben Eisenbraun | Software Sysadmin | | Structural Biology Grid | http://sbgrid.org | | Harvard Medical School | http://hms.harvard.edu |
Re: [COOT] Failure to mount /home/emsley delays coot startup
On 23/06/10 13:26, Schubert, Carsten [PRDUS] wrote: I wonder if anyone has a solution to this problem. We are starting to run coot (0.6.2 pre) on SuSe Enterprise 10.x edition machines. The load times per session are approx 2 minutes, before coot is up and running. Hideous. But I'd mostly lay that at SLED's door, rather than Coot's. Loading with the older RedHat EL 4 machines is almost instantaneous from the same server. A bit of digging revealed that per load of coot ca 3100 lines of error messages are created in /var/log/messages dealing with the inability to find /home/emsley. It was my understanding that the use of LD_LIBRARY_PATH should trump the built-in paths (I mean that the build-in paths should not even be looked up because dynamic libraries are resolved by using LD_LIBRARY_PATH directories). It would seem that SuSe does not do that. Is there any way to get rid of these references in the pre-compiled binaries? Not that I know of (other than by editing). Where should I start digging? It's build into the libraries at a low level. We discussed a means to address this with relative paths a little while ago - that solution has yet to be explored and implemented. I suppose the easiest solution would be to create a /home/emsley and be done with it, urgh. but our IT guys won't do it unless this is the last resort. I am sympathetic that that. Any help to fix this annoyance would be greatly appreciated. You could binary edit the coot-real executable and replace directories that do not exist on your system with others that do (keeping the string length the same). It may help if I made SuSe-specific binaries - one day I'll get a SuSe box (or virtual machine). Or you could build the binaries yourself. Paul.
[COOT] Failure to mount /home/emsley delays coot startup
Hi, I wonder if anyone has a solution to this problem. We are starting to run coot (0.6.2 pre) on SuSe Enterprise 10.x edition machines. The load times per session are approx 2 minutes, before coot is up and running. Loading with the older RedHat EL 4 machines is almost instantaneous from the same server. A bit of digging revealed that per load of coot ca 3100 lines of error messages are created in /var/log/messages dealing with the inability to find /home/emsley. Here is a little excerpt: Jun 23 07:36:31 wrndusshsled01 automount[21265]: mount(nfs): nfs: mount failure rndusshnas01.rndus.na.jnj.com:/vol/vol0/SHhome/emsley on /home/emsley Jun 23 07:36:31 wrndusshsled01 automount[21265]: failed to mount /home/emsley Jun 23 07:36:31 wrndusshsled01 automount[21267]: >> mount: rndusshnas01.rndus.na.jnj.com:/vol/vol0/SHhome/emsley failed, reason given by server: Permission denied Only a few of these entries appear on the RedHat boxes. Is there any way to get rid of these references in the pre-compiled binaries? Where should I start digging? I suppose the easiest solution would be to create a /home/emsley and be done with it, but our IT guys won't do it unless this is the last resort. Any help to fix this annoyance would be greatly appreciated. Cheers, Carsten
