|
Chapters: Responsibilities - Keys - [ Unix Lab ] - PC Lab (210 and 212) - Tools - User Questions3.1 Opening the UNIX Lab
3.2 The UNIX PrintersNOTE: There has been some confusion in the past as to where paper is located and how to acquire it. Paper is kept in 102. If that supply is running low, send mail to labadmin@ccs.neu.edu. If there is a dire need for paper and the Lab Admin can not deliver it in time, then go down to the Systems Office (310 WVH) and ask for some paper for the labs. There are several commands to be used on the printers:
Anywhere that the word 'escher' is used in the previous commands, you can also use 'renoir' to run on that printer's queue instead. Also, job #15 is just an example, these can be run on any job in the queue at the time. The job number can be found by running the lpq -Preiniger command: Printer: reiniger@mordor 'HP800N located in 102 WVH' Queue: 1 printable job Server: pid 14349 active Unspooler: pid 14351 active Status: printing 'ddonahue@algorab+72' starting OF 'ifhp' at 17:41:22.144 Filter_status: (of) getting sync using 'pjl echo' at 17:41:22.384 Rank Owner/ID Class Job Files Size Time active ddonahue@algorab+72 A 72 (stdin) 15031 17:41:21 As you can see here, the following information is available:
With all of this information, it should be relatively easy to find out which job may be jamming in the printer and perhaps why (maybe it's a huge graphic file and it takes a long time to be processed). Tracking down unwanted print jobs and removing them is now much easier than it was before. As always, if there are any questions, email lab-admin. 3.3 UNIX NetworkThe UNIX machines at the College are linked in a complex network environment. Home directories are kept on a large file server, so a user sees the same directory no matter which machines they log on to. Particular machines are also used as mail servers, software servers, print servers, and so on. Further complicating things, our local area network is broken up into a number of subnets, and some servers limit their services to certain subnets. If a particular server computer goes down, or becomes slow due to heavy use or software problems, users may notice problems on their workstations. The workstation may become slow, or some program may hang, or the workstation may freeze altogether. Diagnosing network problems is complex, and the proctors can help us by noticing and reporting details of the networks behavior. When a problem occurs, wait a couple of minutes and see if it goes away; a server may simply be overwhelmed with requests. If a problem persists more than a few minutes, try to send mail to systems. Always note machine names, error messages, the username of the person having problems, and any other information that might be useful. Open the console icon on the workstation having problems to check for error messages. Walk around the lab to see if groups of machines are experiencing problems. It can sometimes be useful for us to know that all the decs, but none of the suns, are having a problem, for example. The more detailed your messages are, the more helpful they are likely to be. Tell us if escher is jammed; but if you check the print queue (lpq -Pescher and notice it has been jamming when a particular job is printing, your mail may be more helpful. Debugging networks involves noticing coincidences. Learn to use UNIX commands like ps- aux|more to see what programs are running on a machine, and df to see how full the disks are. 3.4 Closing the UNIX Lab
|
|||||||||||||||
|
||||||||||||||||