[NOTE: OUTDATED PAGE. GO HERE INSTEAD.]
Getting started with remote/background tasks:
If you're using the packages in this ring, or if you're doing fancy shmancy heavy-duty stuff with Matlab/Maple/Mathematica or your own programs, chances are you have to wait a long time (perhaps days) for your computation to finish. But you don't want to sit in the grad lab for days. There are ways to put tasks in the background, and/or put them on a remote machine. However, be forewarned: it is very easy to piss off other users.
Presently we enjoy self-organization. But if we repeatedly step on each other's toes, and especially if we complain to faculty (even casually at a social gathering), the faculty computer committee may eventually feel compelled to institute some form of micro-management, for example queues, or worse: requiring written proposals before access to the fast machines is granted. Let's work together amicably to avoid such a situation!
Before launching background/remote tasks, you must:
This command displays a list of active processes and how much memory and CPU time each process is using, who owns it, and so on. If a machine is sluggish, top will tell you whose fault it is! Thus top is used by others to determine that your process is pissing them off, and you can use top to ensure your process won't piss anyone off. From within the top display, you can kill or renice one of your processes. Hit ? for some help, but ultimately be sure to read the manpage: man top. (By the way: if you spot someone else's runaway process eating CPU, or someone else's spurious process that might be benign but probably shouldn't be there, either situation may be due to naivety or due to a system bug, so be sure to inform the other user immediately by email. They are the only ones who can correct the situation, and usually they don't know about it unless you inform them.)
Lets you kill one of your processes. You must know the process ID. You can see this in the top display, or you can get a list using ps aux. Instead of using kill as a separate command, you can access it inside top, which you might find easier. Nonetheless, you'll need to learn about kill signals, so read man kill. Generally try to kill something with signal 15 first and wait a few seconds. Ultimately hit it with signal 9. If that doesn't work, then that machine has become unstable and you must report the problem by email to "system@math.arizona.edu". If it's a lab machine, you might put a note over the keyboard, so no one else logs in and loses work when the pending crash occurs.
This starts a task with a nice value, which means the task will share the CPU when other users log in. It is absolutely essential that all heavy-duty tasks and all non-interactive remote tasks be nice. Read the manpage: man nice.
Forgot to start something using nice? Use this to go back and make it nicer. You can also do this inside top. Read the manpage: man renice.
Putting this after a command puts that command in the background. But if you log out, it still gets killed. And it can still suck up lots of CPU. And if it is a command like Mathematica that creates windows, it will create them even from the background. In fact, most people use "&" specifically when starting programs like Mathematica so that they don't lose their prompt. (Try it both ways and the previous sentence will make more sense.)
To put something in the background so that it doesn't die when you logout, start it with nohup. (You also need the "&" for the background part.) You can only do this with text-only batch programs. In other words, the programs shouldn't create windows, they can't rely on keyboard input, and they must send all output to a file. So you can use this with your own C/C++ programs, but you can't use it with most software packages. Go read man nohup. These days, with screen available, the only reason to use nohup is because it is easier to learn than screen, but the latter lets you do so much more.
To prevent a program from using too much time or too much memory, you can set limits in a shell, and all programs started from that shell will have those limits imposed. Use ulimit -a to get a list of limits. To confirm you understand what is going on, set various values ridiculously low and try to run your program to make sure it gets stopped by the operating system. Then quit that shell, open a new shell, and set more reasonable limits. Go read man ulimit.
This creates an environment in which you can start an interactive text-only program, such as GAP or Macaulay, or even Mathematica in its text-only non-notebook mode, but you can log out and it keeps going. It does not automatically make things nice, so you still have to use that as well. Go read man screen. Then you can log in to, say, chivo, start a screen, then inside that screen you can do, say, nice Singular, type some Singular commands that will take days to complete, hit "control-A d", log out, a day later log back in to chivo, do screen -r to reconnect, and you'll be right back in Singular. It's very cool.
This is a graphical version of screen. You can create an entire virtual X desktop and connect to it willy-nilly from home, office, anywhere you can access a web browser. You'll have to read man vncserver and man vncclient, and you might search in Google for "TightVNC" and read the documentation there. Ultimately you'll login to "vnc.math.arizona.edu" and use vncserver to create a virtual screen, then connect from anywhere using either a web browser or special client software. IMPORTANT: Turn OFF your X screensaver on your virtual desktop. It doesn't do this automatically, and you'll hog up the vnc machine with your pointless screensaver. This has happened to three people including a sysadmin. Don't let this happen to you!
Okay. The notes above were just to give a newbie an idea of what the basic tools are. Now you must go out and read documentation and learn the details.