EXERCISE 2: About processes and redirection
Directions |
INTRODUCTION—The numbering below corresponds to “what to type” THE VIRTUAL TERMINAL at the right is a sandbox. A sandbox is a space that may can litter and discard. Long commands may appear in two or three lines. echo 'this is s long command that do not fits a single line, but the END OF LINE goes after the last single quote' |ENTER| But you should type them without pressing enter. The text indicates when you need to press enter. echo "these are:" |ENTER| echo " two different command lines" |ENTER| |
1. ============ I'am logged in —In this sandbox you are root! |
2. ============ What processes am I executing?— I have not issued any command... Yet, you are executing BASH (SH) and you just asked for the running processes (ps command, reports itself at the time of execution) |
3. ============ Now what?— ps was PID 100 now it is 101—It does not make sense! Quite the opposite, it does perfect sense. The first time you execute ps. It ran, reported BASH and itself, then finished, and returned control to BASH. The second time, BASH did execute a new instance of ps and gave it a new process identifier (PID). Every time a program goes to execution, receives its process ID number (PID) form OS. If 10 users run the same program, at the same time, each instance has its own identity. So it can connect to its corresponding input and output channels, neatly. |
4. ============ Let us demonstrate this. Your terminal is named hvc0, and this is what ps did reported to us. In fact when ps was running, it was assigned the same terminal for output, so we could see what it wrote. Here we sent the output to a file, but it appeared in my screen!—Is BASH crazy? Not really, remember everything in UNIX looks like a file, and so do the terminals. /dev/hvc0 is the name of the terminal which I am using. It holds the stdin, stdout and stderr channels (channels 0, 1 and 2 by the way) for the BASH instance that is hosting me, the one with PID 47 (remember?). |
5. ============ Let us run a new program, one very silly, but useful for probing the hardware, output states, etc. Whats going on now the terminal is not responding!—Is this the equivalent of Windows blue screen?😰 The answer is no! 🧐, “yes” writes a sentence over and over again, while it is running in the foreground, BASH is waiting for it to finish only, that it will not ever finish by itself, we have to signal it. To issue a signal while the terminal is not responsive we use a control sequence. The control sequence instructs BASH to signal its child to do something
|
6. ============ Press the keys |CTRL| |Z| at the same time. Excellent, I have recovered control!—but the process is now stopped—and now how do I tell it to start running again? |
7. ============ Well now we have a few possibilities This process is bash’s child, so we can signal it through this BASH. The number in square brackets at the left is its JOB number in this BASH instance. We
may bring it back to the foreground with: We
could send it to the background, we could do that with: “bg
%1”,
though However, can be used to waken processes that do not clobber the screen. For now we shall just terminate “yes”, FOUR ways to do this: fg %1 |ENTER| |CTRL| |C| kill -s TERM %1 |ENTER| kill -s TERM 101 |ENTER| kill -s KILL 101 |ENTER| The first brings the process to the foreground and issues a termination signal. So BASH stops the process. The next three lines will signal yes, the first is through BASH (%1), the second and third is directly through the OS (PID 101). TERM is a kind request for termination, KILL is telling the OS to arrest that nazi and seize his resources ( a sort of PUTIN's attitude, in UNIX programming). The jobs command reports the jobs currently running under the BASH, but only this instance. Its PID is the only way to signal a process started by someone else or in other terminal. |
8. ============ Now we can prevent a program from clobbering my terminal we the use of redirection.
When
we write
When
we use /dev/null is like a black hole it gulps everything you send FOREVER!–and it does radiate heat (amazingly!) |
9. ============ Now we can test how to send this to the background, and because it does not flood my screen with text, I can keep on working. With ps -l we review the running jobs and we can see the state (WCHAN) of each job. The shell is waiting for the user to do something, yes is running and ps was running normally, at the time he wrote its answer. |
10. ============ QUESTION: How do I terminate yes? |
11. ============ A child process dies with its parent We are running bash (PID 300 ) inside bash (PID 47). |
12. ============ Let us run “yes” again, but this time we shall give it a place to write its output and the error messages, if there were any. 2>&1 mean copy stderr into stdout, this will discard any possible message form the program, because the stdout was redirected to /dev/null. Then we had suspended the program, and send it to run in the background with PID 402. |
13. ============ Let us abandon the BASH instance (PID400) that is running inside the starting BASH (PID47). Because the process was running in the background, and has its own channels to write, It becomes independent of its parent, so we can leave and it keeps running. jobs now does not answer anything, because this BASH was not the parent of the yes we are running. so now kill -s TERM %1 will not work, we need to use the file's PID. |
14. ============ When you login in a remote terminal, this behavior of BASH becomes decisive, because most systems will not allow you to stay connected, but inactive, for too long. That means your connection will be closed, and the BASH hosting you will be killed. If your process is not running detached form the BASH instance, it will be killed as well. This is to say, you work very hard, launch your MD simulation, and check it is running. But it is going to take three days. So you close the connection, or perhaps it is closed by the system after 15 of inactivity, and your MD simulation is killed—How annoying! Always run your process using the next syntax: command arguments > output.log 2>&1 & The last ampersand is equivalent to run the process detached from the BASH instance that is calling it. “output.log” is the name of the file where messages will be stored. It can be any name, but make sure it does not exist. Because it will be overwritten. |
15. ============ NOW YOUR TURN: Explain what did happen in each one of the commands WE EXECUTED the previous central cell (these are repeated here for simplicity) |
16. ============ Now a final command: “top” “top” will show you the list of processes with higher priority running in the system and will repeat the scan every second. It also reports memory use, so it is useful to know the load in you system When you need to leave press |q|. Warning: DO NOT PRESS |k| while inside top. If you happen to do it, press |ESC| afterwards. Press |h| for help un the use of top. |
CONGRATULATIONS! YOU HAVE REACHED THE END OF THE TUTORIAL. |