GAMMASPHERE Linux Hints & Kinks, FAQ

Here are some Hints & Kinks pertaining to the GS Linux machines

sender data not getting through

In order for the data from the old DAQ as well as the new DAQ to be sent to the linux machine, the firewall on the linux machine should be disabled. (I have not explored just what parts really need to be disabled).

How do I setup ROOT on the linux machine?

Your .bash_profile should contain these lines

# add path'n stuff to ROOT

export ROOTSYS
export PATH

ROOTSYS should be pointed to the version of ROOT you want to use. After that you should be able to just say 'rootn.exe'

How do I use GSSort

Because GSSort is constanly changing, the best thing to do is download the source code and compile your own version of GSSort and That way you are independent of any new (buggy) versions that may show up and you have full control over how you sort your data -- as well as the ultimate documentation. To compile your own version, do this once
makedir your_data_dir
cd your_data_dir
mkdir src bin
cd src
tar -zxvf src.tgz
cp Makefile.Linux  Makefile.`uname`.`uname -r`
gmake GSSort
  .L Makefile.Linux
cd ..  
now do
  .L src/

what GS disks can the linux machine see?

The linux machine will not mount the disks from the old GS suns properly. Hence, only the disks from the new Solaris machines are available on the machine. You can list them by
  more /etc/auto.home
and they automount as /dk/root1, /dk/root2, etc. If you need some files from the disks of the old suns, you will have to scp them over.

For this reason, the gamuser account on the linux machine cannot share its home directory with the gamuser account on the suns, since the gs filer also will not let the linux machine mount its disks properly.

what went wrong here?[1]

root [1] startsort("bin/GSSort_","","c1.log")
\rm c1.log
rm: cannot remove `c1.log': No such file or directory
bin/GSSort_ -chat > c1.log &
Wed Feb  2 10:38:15 CST 2005
xterm -sl 2000 -T c1.log -e tail -f c1.log &
Wed Feb  2 10:38:15 CST 2005
Remember to (re)load shared memory mapfile or root file
sload("mapfile") or dload("rootfile")
root [2] 
 *** Break *** segmentation violation
 Generating stack trace...
 0x0804b656 in  from bin/GSSort_
 0x0804f770 in  from bin/GSSort_
 0x0804c381 in  from bin/GSSort_
 0x01053e33 in __libc_start_main + 0xe3 from /lib/tls/
 0x080490a9 in __gxx_personality_v0 + 0x71 from bin/GSSort_

[1]You might have the "startmapaddress" wrong. Use "sdummyload" to set the proper address. The proper "startmapaddress" changes from machine to machine and version of ROOT.


[2] sometimes this is seen when GSSort is compiled with the optimizer on. In the Makefile.`uname`.`uname -r`, remove "-O" and recompile. This might be a bug in GSSort, but it is hard to find since the error goes away when GSSort is compiled with -g in order to find the bug in the first place. It could also just be a bug in the optimize. Either of the problems will hopefully go away in the future.