Skip to content

Category: Troubleshooting

determine the libraries / files that an executable is using!!

Published by jweisber on 2014-11-26

ldd   <path/executablename>  lists what libraries it is looking for (or currently using)

ltrace <executablename programarguments>   traces what executable is doing with libs and other stuff and if it gets stuck there’s your problem.  (Note this actually runs program which is why input params are needed)

strace <executablename programarguments> show files opening and closing. This also requires running the program. Since the output is extremely lengthy you might want to save it to blablabla.txt by

$strace -o blablabla.txt <executablename programarguments>

If you want to just trace specific system calls (for example open,read since you are interested in what the program is using) you can type

$strace -e open,read <executablename programarguments>

This will give only open and read calls.

-Yuping Huang

Make Evince Display IDL PS Filename on Banner: JUST USE EVINCE!

Published by admin-joel on 2014-08-19

AS OF 2020 Sep (and I believe much earlier), using the graphics displayer EVINCE automatically puts filename on banner, and furthermore the following did not work with other viewers. Therefore consider the following to be “deprecated” (withdrawn) –jmw

To  actually use evince from the command line, type evince <filename> &

To actually use evince in a nautilus file manager, select (click on) the desired file, and go to
file>>open with>>evince

Commonly when one prints plots to a postscript from IDL and open it with evince(as we always do), the banner of the evince window perennially shows “Graphics Produced By IDL”, which is not helpful at all especially when you’re plotting a thousand plots and trying to compare them.

Hence a pair of IDL routines (OPENPS and CLOSEPS )can be called now to make the output PS file display the file name at the banner and to make the plotting to file process slightly less complicated. The way to call them is as follows:

OPENPS, blablabla.ps      //Before you plot anything. This will set the output device to blablabla.ps and by default color plot

[ DEVICE, FONT_SIZE=9]  //This is the optional part if you want anything about the graph beyond color, see IDL documentation on DEVICE for more

//information. Note that you may overwrite the color attribute here by saying DEVICE,/COLOR=PS

plot,bla

overplot.bla //Plot and add labels and do whatever as you like

CLOSEPS //When you’re done with one graph, simply call CLOSEPS, it will save the file for you and set the plotting device back to xwindows

WARNING: DO CLOSEPS BEFORE YOU OPENPS A NEW FILE. IN OTHER WORDS, EACH PLOT FILE MUST BE ENCLOSED BY A PAIR OF

OPENPS-CLOSEPS statement.

For more information, the code locates at /usr/share/astro/idlshare/locallib, or email huangy@carleton.edu.

 

-yuping

tempo2,fftw3 and cfitsio setup

Published by admin-joel on 2014-08-13

TEMPO 2 is the newer pulsar timing package. FFTW3 is a fast fourier transformation library. CFITSIO is the NASA library for reading FITS format images. All of them are installed under $PSRHOME.  there’s another installation documenting file 00READMECarleton under that folder. FFTW3 and cfitsio are the dependencies for some of the tempo2 plugins and psrchive.

1. FFTW 3.3.4 is obtained from http://www.fftw.org/download.html,  unzip the tar file then

./configure –prefix=$PSRHOME/FFTW3/
sudo make
sudo make check
sudo make install

This will install the double precision FFTW3 library for TEMPO 2. However, the single-precision fftw
library that psrchive might require is not installed yet.

2.CFITSIO 3.370 is obtained from http://heasarc.gsfc.nasa.gov/fitsio/, unzip, cd, then

./configure –prefix=$SOFTWARE_DIR
sudo make shared
sudo make install

3. TEMPO2 is obtained by CVS anonymous checkout
cvs -z3 -d:pserver:anonymous@tempo2.cvs.sourceforge.net:/cvsroot/tempo2 co tempo2

The installation requires an amount of modification of config files (pgplot compilation flag, fixing bugs).
See 00REAMECarleton for details. But basically you do

./bootstrap
 setenv TEMPO2 $PSRHOME/tempo2/
 ./configure --prefix=$PSRHOME/tempo2/ --with-cfitsio-dir=$PSRHOME/cfitsio/ --with-fftw3-dir=$PSRHOME/FFTW3/ F77=f77
 sudo make && sudo make install
 sudo make plugins && sudo make plugins-install

-Yuping

Handy Keyboard Chords

Published by jweisber on 2011-04-19

Due to the current instability with the GNOME environment, here are a few handy key chords to help reset the X windows server.

Press: 
Control-Alt-Backspace To: Kill all running processes attached to the X-Server on the computer and restart the X-Server, Note: As this ends all tasks associated with the X-Server, only use this one if you just turned the computer on or know nobody is using it, though it is the fastest way to restart X and is the only key chord that has any chance of returning GNOME to a functioning state.
                                      
Control-Alt-F1 To: Take you to init-1 (command line), pausing the X server, but not disrupting any open processes. From this command line many smaller tasks can be accomplished, provided that they do not need a separate window to operate.

Control-Alt-F7 To: Bring you back to init-7, (resuming X), use after Control-Alt-F1 to resume the windowing server. You should wait roughly 10 seconds in between using the two commands or the X server will get a little confused. Note: This pair of commands will never bring GNOME back to life, but if you want to work on the computer you can use the init-1 environment to do many simpler tasks.

For more information, as well as a whole host more key combinations please see this website.

Additionally, if one of the computers refuses to cooperate, it is possible to ssh in to any of Linux computers from any *nix system on campus (either a lab Mac, another Linux box, or your own laptop for that matter). To do so type:

ssh -Y username@hostname.physics.carleton.edu

And then enter your password when prompted.

So, for example,

ssh -Y cerjanb@deneb.physics.carleton.edu

Would log me in (provided I entered the correct password) as cerjanb on Deneb.

How fix “Firefox already in use” problem

Published by jweisber on 2009-07-23

Our shared home directories sometimes confuse Firefox, causing it to fail to launch while posting a dialog window saying that “Firefox is already in use”.

The only solution I’ve found that really works is somewhat drastic. It requires you to delete your ~/.mozilla/firefox directory, which has the effect of deleting your bookmarks.

To preserve your bookmarks, we must first export them to a temporary location, exit Firefox, delete your ~/.mozilla/firefox directory, relaunch Firefox, and then import your bookmarks from the temporary location.

Here’s the step by step solution:

1. To get Firefox to launch (in a somewhat hosed state) so that you can save your bookmarks, open a terminal window and issue these commands:

rm -f ~/.mozilla/firefox/*.default/lock
rm -f ~/.mozilla/firefox/*.default/.parentlock

2. Launch Firefox. It will be somewhat hosed, but you should be able to export your bookmarks by opening the Bookmarks window by selecting “Bookmarks->Organize Bookmarks” from the Browsers menu. Once the Bookmarks window appears, click on the “Import and Backup” menu and select “Backup”. A “Bookmarks backup” window will pop up prompting you for a location to save your bookmarks to. Just go with the default values, which should save a “Bookmarks <date>.json” file to your Desktop.

3. Exit Firefox

4. From a terminal window, issue this command:

rm -f ~/.mozilla/firefox/

5. Launch Firefox. At this point Firefox should behave normally and you can restore your bookmarks by opening the Bookmarks window and selecting “Bookmarks->Organize Bookmarks” from the Browsers menu. Once the Bookmarks window appears launched, click on the “Import and Backup” menu and select “Restore”. A dropdown list of of bookmark backup files should pop up, and you can select the most recent one to restore your bookmarks.

Kernel modules must be present on RHEL >= 5.3

Published by jweisber on 2009-02-20

Updates to the RHEL kernel change the location of and/or delete any custom kernel modules that have been compiled (this applies most notably right now to graphics drivers). In the past this has been OK as I usually just recompile any modules against the new kernel after updating. Unfortunately, it seems that, starting in RHEL 5.3, the kernel will panic whenever it is asked to load a module that does not exist, instead of just throwing a polite error.

I noticed this with graphics drivers – the machine screen will go blank AND ssh will not function if X11 asks the kernel to load a graphics driver module that no longer exists. So, it is important when updating kernels now to remove any references to custom modules (i.e., modules not managed by yum) prior to rebooting after a kernel update. (Yet another reason that we don’t pull down kernel updates automatically!)

In the case of the graphics driver — which is the only custom module as of Feb 2009 — this is painless because the driver installer backs up the vanilla conf file. This means that you have to delete /etc/X11/xorg.conf and rename /etc/X11/xorg.conf.original-x (the vanilla backup, where “x” is a small integer or zero) to /etc/X11/xorg.conf prior to reboot. If you forget, you must boot into knoppix or something similar off a CD, mount the hard disk and make this same change.

-James

Issues Upgrading from RHEL 5.2 to 5.3

Published by jweisber on 2009-02-04

As of the date of this posting, the latest version of Red Hat — and the version being used on all astronet machines — is 5.3, identified by kernel versions >= 2.6.18-128

If for some reason it ever becomes the case that a machine must be upgraded from 5.x to 5.3, Bruce and I ran into some hiccups in yum regarding the updating process.

Ideally, machines can be upgraded to a new RHEL release version simply by
1.) Removing any excluded packages by commenting out any exclude=XXXXX lines in /etc/yum.conf
2.) Running yum -y upgrade
3.) Coming back ~25 mins later and rebooting the machine.
4.) Uncommenting the traditional package excludes so updating can continue automatically as before

Unfortunately, as of this posting the 5.3 version of the tog-pegasus package from RedHat refuses to do an update install – and in fact hangs the update process. All of our machines that were up-and-running when 5.3 was released tried to get this package (because of our automatic update cron job) and the yum process was permanently hung.

The fix:
1.) See if any yum processes are currently being hung up by tog-pegasus
>> ps auxwww | grep -i yum
2.) If there are any yum processes running, and it looks like they’ve been running for a while, they’re probably hung. Reboot to kill the processes.
3.) When you’re back online, check again to see if any yum processes are running and kill (all of) them.
>> ps auxwww | grep -i yum
>> kill -9 <PIDs>
4.) Uninstall the following packages (tog-pegasus and openoffice must be wholly removed)
>> yum erase tog-pegasus openoffice.org-*
5.) Remove any excluded packages by commenting out any exclude=XXXXX lines in /etc/yum.conf
6.) Now try the update again
>> yum -y upgrade
7.) Come back in ~25 mins and make sure everything has completed. When yum tells you it’s done, reboot.
8.) Reinstall openoffice by running the script below or by hand with yum install
>> /etc/secret/clientconfig/install-programs/install-programs.sh
9.) Clear yum’s unfinished-transaction log so it forgets about the whole ordeal and doesn’t bug us about it
>> yum-complete-transaction –cleanup-only

Don’t bother reinstalling tog-pegasus, it’s nothing we will ever need.

**AS OF 2/4/2009 AND TO THE EXTENT OF MY KNOWLEDGE, ALL ASTRONET MACHINES ARE UPGRADED TO RHEL 5.3 AND FUNCTIONING**

Change users quota (MUST BE *THUBAN* ROOT)

Published by jweisber on 2008-07-09

type edquota <username> as root on thuban.

this drops you into a vi editing session.

change the quota as desired and then exit the session.

If you are not familiar with vi, you may find more details on how to edit this file under the “new user” post, where the setting up of a quota for a new user is discussed.

–Joel

Thuban reboot issues

Published by jweisber on 2007-07-22

Thuban as the server, is more sensitive to rebooting than other machines. Therefore do not reboot thuban unless absolutely necessary.

If it is rebooted, be sure that it has exported all the shared disks for use on other astro net clients. To check that this has successfully happened, log in to another desktop and try cd-ing to various shared disks like /data/psrdata and /docs and so on. If thuban has NOT mounted these disks for sharing, then James Fuller says to enter the following command on thuban:

(as root):# /usr/sbin/exportfs -a

–Joel