Skip to content

Category: Troubleshooting

Hitting disk space limit? Near disk quota?

Published by admin-joel on 2024-07-03

If you see funny behavior on your account, it might be that you are running out of disk space.
A good citizen might do the following every few months, but that ain’t me babe.

The command :   quota         will tell you how close you are to your quota.

If you are close (or over!!!), then it’s probably junk files doing it, which can safely be trashed.

But how to find the culprits?  How to separate the chaff from the wheat?

(See update at bottom for some of Bruce’s tips on how to find offending files,
but immediately below this line are Joel’s less sophisticated directions.)

du -ak | sort -n | tail   will give you a list of the biggest dozen or so files.  That, of
course, doesn’t necessarily mean they are trash.  But common places
with lots of trash are (in my experience)

<your home directory>.Mathematica/Paclets/Temporary      (note the dot before Mathematica!)                                      This often has enormous garbage there. Clear out any contents (but
probably not the directory “Temporary” itself.). I had the courage to byte
this bullet after reading
https://mathematica.stackexchange.com/questions/64130/mathematica-appdata-folder-is-taking-up-too-much-space
Note that the comment there also makes the reasonable statement that
the contents of any directory called Temporary or the like are fair game!

<your home directory>.mozilla/firefox will have one or more directories with gibberish names.
(note the dot before mozilla!)
If there is more than one, than trash all but the newest.

For me at least, even in the newest, I had a cache2 directory whose enormous contents I
trashed.  I also googled how to force firefox to automatically clear its cache
whenever firefox is logged out so that this garbage doesn’t accumulate!

Here are Bruce’s more sophisticated directions from an email on July 15, 2024:

I ran this report:
du -hx /var/share/home/curtina | grep -P ‘^[^\s]+M’

 

 

 

When Mirzam can’t be ssh-ed into (usually after reboot)

Published by admin-joel on 2023-10-16

When Mirzam can’t be ssh-ed into (usually after reboot):

/home and other NFS volumes exported by thuban2 probably aren’t mounted.
 
They should have automounted when mirzam was rebooted because they’re listed in /etc/fstab.

The fix is to login as root (which does not require /home) and then run the ‘mount -a’ command.

Bruce

Joel adds:  One needs root’s password in order to pull this off!

To edit much of IDL source incl say coyote: must be on thuban2 on root and centos7

Published by admin-joel on 2022-07-05

Because mirzam was down tonight I used idl on canopus instead. In trying to run some idl galactic magnetic field idl programs on canopus, I kept hitting an obscure error on coyote’s cggreek routine which makes greek letters for plots.  Googling it I found that an idl 8.6.1 (as on canny) error prevented old cggreek from working.  (It worked ok forever on mirzy, which has I think idl 8.7)

So I installed the new cggreek from github to thuban2’s /var/share/astro/idleshare/coyote.  but this didn’t work!  why?  because i had to install it onto /var/share/astro_centos7/idleshare/coyote   Note because of access issues, one can not install directly onto /usr/share/astro on mirzy or canny, but must instead go to thuban2/var/share/astro_centos7/ as above (and see below).

by the way i used su cp etc etc on thuban 2 to overcome permission issues on canny or mirzy themselves, but prev post shows that su – on thuban2 might be easier

Ssh security

Published by jweisber on 2021-03-04

Directions from Bruce. (BDUFFY 2021-02-17. )Thanks Bruce! Slightly updated by Joel. These were specifically for setting up to ssh to new mirzam, but are relevant for any new host.

Remove old mirzam entries from your ~/.ssh/known_hosts file  (It looks like very long lines of gibberish. A hostname or its internet number [ie 137.22.301.5] starts each line.)

The next time you ssh into to an astronet machine, ssh will ask you

(base) bduffy66924:~ bduffy$ ssh bduffy@mirzam.physics.carleton.edu
The authenticity of host ‘mirzam.physics.carleton.edu (137.22.6.129)’ can’t be established.
ECDSA key fingerprint is SHA256:nersU93cf8F5ucysog/Rn2OIbSabknw10hpw5uXFs3o.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘mirzam.physics.carleton.edu’ (ECDSA) to the list of known hosts.
bduffy@mirzam.physics.carleton.edu: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
(base) bduffy66924:~ bduffy$

See ./astronet-server-ssh-public-keys.txt

2021 05 17:  JMW does not know what directory ^ this is in.

Also, I had to add the authorized_keys file to one of my home macs’ .ssh directory in order to get all the way in to canopus.  See email from Bruce on 2021 05 17 for more details.

clear firefox cache cleanly to free up space and not overflow quota

Published by jweisber on 2020-05-26

A cleaner way to free up firefox cache space, was provided by Mike Tie via Bruce Duffy.

I noticed I couldnt log in to carleton email via astronet firefox and these guys said it was because of a carcass in cache. So this is the procedure for clearing cache, which can also often bring a user’s space down below their quota limit:

Firefox has cached the old info, and now you need to clear the firefox cache. To do that, Launch firefox, click the three bars in the upper right corner of the firefox window, click Preferences, click the lock icon (middle left of the window), scroll down to “Coookies and Site Data”, click on “Clear Data…”, make sure both items are checked, and click “Clear”, and then click “Clear Now”.

fixing problems with pgplot and cpgplot: building them and linking them to our own pgms

Published by jweisber on 2017-01-22

See updates at bottom from building pgplot and cpgplot on phasshare virtual 64 bit machine

First, recall that there is a pgplot-32bits (obsolete as of 2021 Feb ) and a pgplot (now 64) directory

On Aug 2, 2016, Yuping suggested putting cpgplot.h into /usr/include  .  Note this is NOT a shared directory so will need to be done on whatever host one is working on. If it is not there and one tries to build cpgplot, it will fail.

Another possible problem could occur when trying to link pgplot or cpgplot to a program.

e.g; the (64 bit) linking command

gfortran -o LKBorig LKBorig.o -L/usr/share/astro/psrhome/pgplot -lpgplot -lcpgplot -L/usr/lib64 -lX11 -lm -lstdc++ -lpng -lz

(cpgplot is just a c wrapper for pgplot and Yuping says it was actually pgplot that was damaged or missing.) (But see below 2021 Feb 3 update for a related prob- there we need to type ‘make cpg’  to make libcpgplot.a   . I dont think we use lib….so any more)

–Joel (with help from Yuping)

Update 2021 Feb 3 JMW: Creating pgplot and cpgplot on phasshare 64 bit virtual machine:

First, don’t ignore above advice about certain special files and their placement.

Second, Bruce and Joel could only get cpgplot programs to work by seeing how libcpgplot.a was created and linked , in psrchive  directory(much more below)!

To create a fresh pgplot and cpgplot that work, execute pgplot.csh in the bowels of psrchive:

/usr/share/astro/psrhome/src/psrchive/packages>
./pgplot.csh | tee /usr/share/astro/psrhome/pgplot/pgplot.csh.out
(tee sends the text  output to the named file  in addition to standard output). See a fuller description of what pgplot.csh does below.

(User must move the previous pgplot out of the way before running this script; ie
mv /usr/share/astro/psrhome/src/pgplot/ /usr/share/astro/psrhome/src/pgplot.older/)

(And I worry that maybe I need to move other random carcasses out of the way too.)

Some of the things done by pgplot.csh:
1. create a mother directory to put all necessary pgplot files into:
/usr/share/astro/psrhome/src/pgplot, after first moving aside the current tree there (see above).Actually it creates /usr/share/astro/psrhome/src/ and then will pour everything below it.)
2. Also create /usr/share/astro/psrhome/pgplot/ (I wonder if we should have moved old one out of way here too?)
3. get if necessary and gunzip and de-tar the pgplot 5.2  distribution (!)  and put it into and under newly created mother dir.
4 patch the png routines: Interestingly, there is a file
/usr/share/astro/psrhome/src/psrchive/packages/pndriv.patch which seems to suggest that there might indeed be probs with standard png driver, and it is pulled in by pgplot.csh and does seem to enable the use of png routines with pgplot and I assume cpgplot.
5. fix psrchive.conf
6. enable good output drivers
7. run /usr/share/astro/psrhome/src/pgplot/makemake with appropriate flags, creating master makefile, and ‘make’ -ing it and ‘make cpg’ -ing it.  As far as I can tell, the makefile made from this process is essentially identical to the earlier one(s), except that the earlier ones could not link in the png routines because they were broken, but the current ones are patched by pgplot.csh  (perhaps not in makefile itself but rather in something it calls.)

But for now consider the following:

lots of pgplot source files are in
/usr/share/astro/psrhome/src/pgplot/src/
cpgplot files are in
/usr/share/astro/psrhome/src/pgplot/cpg/  (see cpgplot.doc here for important help and note that pgbind.c ,which is run by ‘make cpg’, actually makes the libcpgplot.a I believe)

Note that the two above directories are not parallel nor do they have any other logical relative location!!!

pgplot executable etc dir is /usr/share/astro/psrhome/pgplot/  One can find things like makefile (manually placed there), libpgplot.a, libcpgplot.a cpgdemo, pgplot.csh.out (the text output of the proper building  of cpgplot (and pgplot) via running pgplot.csh as follows:
/usr/share/astro/psrhome/src/psrchive/packages>
./pgplot.csh | tee /usr/share/astro/psrhome/pgplot.csh.out  (tee sends the output to the file  in addition to   standard output)

Note makefile can be created by makemake in /usr/share/astro/psrhome/pgplot/src/pgplot and in fact running makemake in that dir places makefile there too, so I manually moved it up two directories.

makemake /usr/share/astro/psrhome/src/pgplot/ linux psrchive   [the latter three ‘words’  are the arguments of the makmake command], which erroneously dumped makefile into the above specified dir (upon its own reccomendation) so I had to manually mv it to /usr/share/astro/psrhome/pgplot/     .  In the end I had to make from the above  psrchive version in order successfully to create cpg or at least the png parts of it, and to successfully link cpgdemo.

then ‘make’ makes libpgplot.a  and ‘make cpg’ makes libcpgplot.a  (see steps near bottom of that file)!  There is a problem with png routines though that crashes? (or at least reports errors in) the make cpg  but the psrchive-generated makefile fixes this!

 

More serious problem with cpgplot (fixed by Bruce and Joel 20210204):
If I try to build any c (.c) or c++ (.C)  program and link it with cpgplot up thru Feb 3, it failed because it couldn’t find ANY of the cpgplot routines that the program tries to call. (eg the creation of cpgdemo inside the make cpg part of the makefile, or the pglink64plkc.C script for compiling and linking plkc.C in usr4/lk-lookey). Note that cpgplot is just a c wrapper to fortran pgplot routines and that is what is failing.  Long ago we had this problem and it was fixed by adding a trailing “_” to any fortran routine name.  I see that that is being done now but it doesn’t fix the problem (maybe it exacerbates it?). One example of failure (there are many, one for each unique call of a cpgplot routine):

{phasshare.physics.carleton.edu}:{jweisber}:/data/psrdata/usr4/lk-lookey> pglink64plkc.C
/usr/share/astro/psrhome/pgplot/libcpgplot.a(cpgbeg.o): In function `cpgbeg’:
cpgbeg.c:(.text+0x34): undefined reference to `pgbeg_’

The fix of Feb 4 was to model our 64bit compile and link scripts
(like /usr/share/astro/pglink64cpgdemo.C), on the (more automated) steps that
successfully create it in the makefile.  So now /usr/share/astro/pglink64cpgdemo.C is
my template for making other 64 bit, c compile and link scripts. . . .

I found on Feb 5 that .C (ie capital C) files like usr4/lk-lookey plkc.C can not use the same script as .c (ie lower case c) files because the .C files are c++.  After a (too long) while, I got working a script to do so.

So for a c file <filename.c> one types pglink64.c  <filename>  (with extension stripped off), and

for a c++ file <filename.C> one types pglink64.C  <filename>  (with extension stripped off)

( There may be slight path issues. )  Both scripts are in /usr/share/astro on phasshare

 

spreadsheet csv file reading issues and solutions

Published by jweisber on 2016-11-10

We imported a spreadsheet as csv but couldnt edit it in kate. It said “R/O” [=readonly]  Bruce helped us come up with several fixes:  (Thanks Bruce!)

  1. He installed  on Deneb and Canopus “libreoffice, including ‘calc’, which is an open implementation of Excel.  That’s a nice GUI way to edit .csv files.”    https://wiki.documentfoundation.org/ReleaseNotes/5.2  .  You can launch from the Office menu or via the command line as ‘libreoffice –calc <filename> &’
  2. He found that the problem is that the carriage returns are the wrong format, by using the file command:
    file Summary_edited_JoelNov.csv

        Summary_edited_JoelNov.csv: ISO-8859 text, with very long lines, with CRLF line terminators

    He says that this indicates that the csv has dos-type CRLF, not unixtype.  So he installed dos2unix and ran:

    dos2unix < Summary_edited_JoelNov.csv > Summary_edited_JoelNov.unix.csv    and now
    file Summary_edited_JoelNov.unix.csv

    Summary_edited_JoelNov.unix.csv: ISO-8859 text, with very long lines  ,
    so it is fixed and editable with kate

  3. vim or vi work on the original, even with “bad” CRLF

–Joel

When the IDL license manager halts for no good reason on canopus…

Published by admin-joel on 2016-03-17

Updated by Bruce and Joel July 2019

So apparently the license manager for idl on canopus loses connection to the server from time to time and Bruce found out that the best way to deal with it was just to power cycle it. Yuping encountered the problem again today and tried the following and it worked.

sudo su – (puts one into root and bash shell – must have sudo privileges)

$ cd /usr/local/exelis/idl83

This is where the IDL installation is

$./bin/lmutil lmdown

This will kill all of the license managers.

$ps aux|grep lm

Make sure that all lm’s are killed

$ ./bin/lmgrd > lmgrd-201Y-MM-DD.log

imgrd starts the license managers.

This appears to fix the problem.

-Yuping

On 2016-05-26, joel found that the above did not quitre work without some help.  I had to first create the log file with a sudo touch filename command, and then CONCAT to the log file in the above sh command by adding a second > to the first one.

Login Hangs After CentOS/RedHat Kernel Update

Published by admin-joel on 2015-06-15

June 15, 2015

A second incident of login getting hung after kernel update is found. The first incident was reported on Aug 2, 2014. As usual when users type in user name and password at the login window and hit login the login process gets frozen and cannot get to the desktop. It appeared to only affect tsch (using .cshrc) users.

The solution is to hit ctrl-c and then rm .history to get rid of the .history file. Note that if you do it from ssh, it might cause the host to reboot.

Canopus and Algol got updated over the weekend to kernel version 2.6.32-504.23.4.el6.x86_64. Hence it seems like it is only affecting these two hosts.

-Yuping & Bruce