Difference between revisions of "Tardis Beginner Tutorials/8"
m (Text replace - "<div style="width:55%;margin:0 auto;border:2px solid;border-left:20px solid;border-color:#d9534f;text-align:center;padding:5px;font-weight:bold;">This page is out of date and needs rewriting.<br /> The content is likely to be incomplete or)
|Line 1:||Line 1:|
=Tutorial 8: Monitoring and manipulating your processes=
=Tutorial 8: Monitoring and manipulating your processes=
==The foreground and the background==
==The foreground and the background==
Latest revision as of 23:23, 12 October 2013
Tutorial 8: Monitoring and manipulating your processes
The foreground and the background
You don't need to use screen to multitask in linux - bash provides some methods of elementary process control that you ought to know about. By default a process (any program you run) will run in foreground - meaning your user input will be piped to it rather than the shell or any other program. It is possible to make a program run in background instead, simply by appending & to the commandline - for instance, try running:
Instead of the familiar full-screen display, you will get a pair of numbers - the one in square brackets (probably "1") is the number of the backgrounded process belonging to you (this is the "job number" - don't confuse this with PID), and the second number is the Process ID (PID) which is used to globally refer to the process - to kill it, change its priority, etc - once it is running. While the PID is accessable to anyone on the machine, the other number is only for your own use in the following two commands - fg and bg. You can use fg or bg on their own to bring a specified process to the foreground or the background. If a process is not in the foreground it is either already in the background or it's stopped - you can usually stop a foreground process by pressing ^z (ctrl-z). This will freeze it, and return you to the prompt - then you can either type bg to allow it to run in the background, without your input, or fg to bring it back to the foreground. Now try bringing top back to foreground by typing:
Optionally, you could type fg 1 or whatever the first number was to bring back a specific process, if you have more than one running in the background or stopped. By default, fg on its own will bring back the last process that left the foreground. Instead of the number, you can also use the name or the first few letters of the name of the process. The other command, bg, works exactly the same way (except of course you can't put a program that's running in the foreground into the background with it, simply because you don't have the shell to type it into - you have to stop it first with ^z).
Listing, killing and renicing processes
You will not be the only one running processes on the tardis machine you are logged in to - as well as the processes the machine runs itself, such as network services and daemons, you will be sharing memory and processor time with other regular users, who may only be running mutt to check their mail, or may be compiling large amounts of source code. The responsiveness of the system is therefore connected to the current demand for it. To cope with many users running many processes, linux has a threads and priorities system which we can control to a small degree as a normal user.
To see who is connected to the same machine you are, type w - this lists all usernames, where they are connected from if they are logged in from the internet or another tardis machine, when they logged in, how long they've been idle, how much cpu time they are using on average, and what they are currently running in foreground.
To list the processes you have running you can simply type ps. You will likely only see two - bash, and ps itself. The command ps is much more powerful however, and has many commandline options to modify the output. My preferred ps commandline is:
This lists all processes, with users listed with their processes, regardless of tty (x), and with an ascii-art forest style process hierarchy display (which shows graphically which processes are children to which). The output is rather long - it shows both userland and system processes. Scroll back up it by pressing shift-pageup, or alternatively pipe the output to the pager less:
ps auxf | less
You may spot some interesting stuff going on - the process list is constantly changing, so no two ps outputs will be the same. The most useful thing to be found on the process list is the PID - the four or five digit number on the left. It is this number you use to reference individual processes.
The other useful thing to understand is priority of a process. A process can be assigned a priority, which tells the kernel how much cpu time it should be given relative to other processes. For a non-root user, priorities range from 0 to 19 where 0 is the most cpu time (demands the process' maximum fair share of cpu time available) and 19 is the least (the lowest priority) - meaning it will use only idle cpu time that no other process wants. It is also possible to have negative priorities, where processes aggressively grab cpu time whether they need it or not, but only the root user can create those. Also only the root user can increase the priority of a process (reduce the number), although the user can create his processes with any priority between 0 and 19, and reduce the priority (increase the number) while it is running. Note however that the priority the user assigns their process is only taken as a guide by the kernel, and the kernel will assign a lower real priority based on system load etc. The priority you assign a process is called its niced priority, and you can see both the real and niced priority in top - have a look now. It seems that nobody knows exactly why it's called "nice", but people seem to think it's to do with making the process "behave nicely". by not hogging unnecessary resources. You can make your own processes nicer with the renice command - have a read of man renice now, because it's fairly versatile.
Now let's try some advanced process manipulation. We are going to create a resource hogging process, but then stop it, make it play nice, and eventually kill it altogether before it can complete. First let's log in a second time, so we can watch how our process behaves. Log in as described in the first tutorial, and run top in the new window. Now go back to your other shell window - it's time to create a resource hogging process that will never end:
grep sillystringthatwontbefound /dev/urandom
This will search the system random "device" for an exact match of a silly string that is rather unlikely to be found. This process will never end, and will use as much cpu time as the kernel is willing to give it. Run this now, and watch it appear at the top of the list in your other shell window running top. You will see in the CPU column that it's using considerably more cpu time than any other process (unless you're unlucky and the machine is heavily loaded at the moment), and you will see the kernel changing its priority constantly to balance its demands with those of the rest of the system, while the "nice" column remains at zero.
Now we will make our resource hog play a little nicer. Let's stop our process by pressing ^z (ctrl-z). Note how it's no longer taking up any cpu time, if you look at top. Now let's put it in the background by typing bg and see it spring back up on the top list. Now we have a shell prompt we can take control of the process, so let's tame it a bit. We'll need the PID of the process, so copy it from the list in top - you can copy by just selecting the text, and paste it when you need to by right-clicking in the window. Now we know the PID, we can change its priority:
renice +10 [PID of our process]
Now have a look at the listing in top again - our nice priority has been increased, but if the system is as busy when you try it as when i was writing this, you'll find the actual priority doesn't change at all because it's a higher number to start with than your nice priority. Your nice priority is just saying to the kernel that your process doesn't need to go over a certain priority. So let's force our resource hog to absolute minimum priority:
renice +19 [PID of our process]
Now we see the process' priority has dropped to 19 and if any process at all wants more cpu time our grep will step out of the way.
Now to finish off, let's kill the process. We could just bring it back to foreground and interrupt it by pressing ^c, but killing it is pretty much the same. This is what you want to do if a process stops responding, or behaves in a way you don't want it to and you can't stop it in a more friendly way. Try it now - simply type: kill [PID of process] It should now have disappeared from the processes list. Sometimes uncooperative processes don't die with just the standard TERM signal, in which case you want to send it a KILL signal by typing: kill -s 9 [PID of process] It's worth reading man kill as it explains different signals - you will see that kill can be used to send other signals to processes, such as HUP which is used fairly often. Now you know how to control processes you run, you should be able to do pretty much everything you need on tardis. The next few tutorials will teach you to use ssh and wget to copy files across to your tardis account to do things like upload your website to tardis, and download software source files to compile in our last tutorial. By the time you complete these tutorials, you should know how to do pretty much anything you might want on tardis.
Next: Advanced SSH Usage