Resources
Unattended Processes
Sometimes a process will run for long periods of time, i.e. several hours or days, without user interaction. This may happen either deliberately or inadvertently. We'll call such a process an unattended process.
An unattended process that's not accumulating CPU time is an idle process. Such processes generally don't hurt anything and the Lab staff does not kill them. (Exception: an idle process that seems to present a security risk, for example a shell process left running on a public terminal, will be killed if we notice it.) However, if it's necessary to reboot a machine or do anything else that kills the process, the Lab will assume that its demise will not be a great loss and will proceed accordingly.
An unattended process that's running up large amounts of CPU time, e.g. hours, has a significant impact by slowing down other processes. Historically, such occurrences have usually been unplanned malfunctions, especially if the process name is a recognizable system program such as vi. If we can't contact the owner and a process looks like an inadvertent runaway, the Lab will suspend it so that the rest of the system will function better. Suspended jobs may be reactivated by the owner at a future time if appropriate.
Because of the nature of the type of user, Departmental machines supporting student course accounts, e.g. Lectura, will be handled somewhat differently from the above. Any process owned by a student not logged in is subject to being killed by the Lab staff.
We will handle borderline cases by applying our best judgment in
conformance with the spirit of these guidelines. If you are going to
deliberately run a long CPU grinder (such as an overnight MACSYMA run) it would
be prudent to mail a short note to lab. This will remove our doubt and
give you peace of mind.
Last updated January 7, 2008, by John Luiten
Send questions about this page to