FAQ

This page presents a list of Frequently Asked Questions (and answers) about using the HPC cluster system at the University of Iowa.

How do I access snapshots of my home account?

Snapshots are available as read-only directories in ~/.zfs/snapshot, each representing the state of your home directory at the time the snapshot was created. To restore a file or directory, use the cp command to copy it from a snapshot directory under the snapshot folder to a writable location in your home account (or elsewhere if you prefer). Here is an example of what you might expect to see during the restore process:

[brogers@login-0-1:~]$ cd ~/.zfs/snapshot

[brogers@login-0-1:snapshot]$ ls
zfs-auto-snap.daily-2011-02-10-00.00   zfs-auto-snap.monthly-2010-10-25-08.58  zfs-auto-snap.weekly-2011-01-22-00.00
zfs-auto-snap.daily-2011-02-11-00.00   zfs-auto-snap.monthly-2010-11-01-00.00  zfs-auto-snap.weekly-2011-01-29-00.00
zfs-auto-snap.daily-2011-02-12-00.00   zfs-auto-snap.monthly-2010-12-01-00.00  zfs-auto-snap.weekly-2011-02-01-00.00
zfs-auto-snap.hourly-2011-02-11-16.00  zfs-auto-snap.monthly-2011-01-01-00.00  zfs-auto-snap.weekly-2011-02-08-00.00
zfs-auto-snap.hourly-2011-02-11-20.00  zfs-auto-snap.monthly-2011-02-01-00.00
zfs-auto-snap.hourly-2011-02-12-00.00  zfs-auto-snap.weekly-2011-01-15-00.00

[brogers@login-0-1:snapshot]$ cd zfs-auto-snap.monthly-2011-01-01-00.00/

[brogers@login-0-1:zfs-auto-snap.monthly-2011-01-01-00.00]$ cp computeilos ~/

How do I see the status of just my jobs with qstat?

The qstat command defaults to showing the status of all jobs. However, to view the status of just your own or another user's jobs, one can pass the '-u' flag to qstat. So, to see the status of jobs submitted by user jdoe:

qstat -u jdoe

"Could not connect to session bus" when connecting to Argon using FastX version 2:

When connecting to Argon with FastX version 2, you may see an error saying "Could not connect to session bus: Failed to connect to socket" while starting a graphical desktop such as MATE. The most common cause of this issue on Argon is that you have installed Anaconda using its default settings. Anaconda's installer configures your ~/.bashrc file to automatically activate Anaconda during the login process. But the installer also gives priority to Anaconda software, and because Anaconda includes software which interferes with graphical logins, its presence causes them to fail with this error.

In older versions of Anaconda, the installer simply adds its own path at the start of the PATH variable, so you can work around the problem by moving its path to the end, thus giving Anaconda software lower priority. That is, edit your ~/.bashrc to change the definition like so:

FROM:

export PATH="/Users/YOURHAWKID/anaconda2/bin:$PATH”

TO:

export PATH="$PATH:/Users/YOURHAWKID/anaconda2/bin”

More recent versions of Anaconda configure activation in your ~/.bashrc using a very different mechanism, and a fix analogous to the above is less convenient. In this case, you can leave that configuration in place so that Anaconda itself becomes active during login, but reconfigure Anaconda so that the default "base" environment is not automatically activated during login. You can use the standard conda commands in your shell session or job script to activate any environment when you need to use it.

I see jobs pending in my queue from people who do not have access.

There are two possible reasons for this. The first is that the person submitted to the wrong queue. The job will not run in your queue and these are generally cleared out pretty quickly, because the person wants to get their job running. The other case is due to a bug in SGE where the queue listings for array jobs with dependency holds are not accurate. If a predecessor job has not started, because it also has a hold, then jobs will show up in ALL queues in the hqw state. Basically, SGE is not sure yet where the array job belongs so it lists it as being queued in all of the queues. Since these are jobs in a hold state, waiting for other jobs in a hold state, these jobs could display in all of the queues for quite some time. Those jobs will only launch to a queue that the job owner has access to. This erroneous display status is a bug, or perhaps a poor implementation of getting status from array jobs, but there is not much to be done since SGE is not actively developed.

Filezilla shows the following error when connecting:

Error:        	Server sent an additional login prompt. You need to use the interactive login type.
Error:        	Critical error: Could not connect to server

This is because the Duo prompt can not be shown. In the "Site Manager", select "Interactive" from the drop-down selector for "Logon Type". That will cause a dialog box to pop up where the Duo information can be entered.

Filezilla keeps trying to reconnect

This is the default behavior for filezilla. Set the timeout to 0 in the settings.

System based programs fail to load after loading environment modules

The environment modules set up the environment for the respective applications. While most library paths are baked in, it is still necessary to provide a hint to the path of libraries for many things. Due to this, the LD_LIBRARY_PATH variable is set to ensure that module packages are finding the correct libraries. Unfortunately, that can cause issues when trying to launch non-module programs, ie., programs that are available on the system without using environment modules. If you see error messages related to libraries when launching a system program you will have to unset LD_LIBRARY_PATH. There are two options:

Launch programs from a session without any modules loaded. The environment can be reset with
```
module reset
```
Unset LD_LIBRARY_PATH as part of the command. For example
```
LD_LIBRARY_PATH='' gedit
```