Flash Advertise
| Processed Linux: from exec to exit |
| 摘自: www.itwire.com 被阅读次数: 73 |
由 yangyi 于 2008-05-01 23:00:48 提供 |
Linux is a multitasking operating system, running many tasks – or processes – seemingly at once. Every process leaves a footprint on your system. Here are some tools to examine these, and we also work out just what that creepy /proc directory is all about. Welcome back. Over the last weeks we looked at how the Linux scheduler prioritised the processes to run, and learned about jiffies and zombies. Now it’s time to cover the life cycle of a Linux process and just what happens when you run a program. Linux enforces strong family values through parent/child relationships. Every single process except for one has a parent process. The one exception is init which is the granddaddy of everything else. This is process number 1, the big kahuna which fires when Linux first boots. Every other process has been spawned from it, either directly or through its offspring. Like some types of worms and fish, Linux processes have only one parent. And, like guinea pigs and rabbits, a Linux process can have almost any number of children. Users of a Linux system create processes when they execute command-line instructions or when they double-click on icons and menu options within the GUI environment. Behind the scenes, the applications invoked come to life because they are spawned by a parent process – whether it be a BASH shell, for instance, or the KDE or Gnome desktop. And, if a program creates another task then it is making a child process of its own. This happens all the time. It’s what Apache does when a web page request comes in, for example. Apache spawns a new process to take care of the incoming connection so the main body of the program is freed up instantly and can listen for new incoming requests. If it didn’t spawn off a child process, the web server may become unusable by others because its time is taken up serving the first request instead of responding to newcomers. Behind the scenes, these processes are made through one of but three system calls within the Linux kernel. Two of these have a shared UNIX heritage, fork and vfork, whereas the third one is specific to Linux and is called clone. fork is the historically preferred way to create new processes. The fork system call splits the process in two, leaving a parent and a child process. The parent is the original process, retaining the process ID it had since it began, and receiving the process ID of the child as a return value from fork. The child process, however, is a duplicate running in a new process space with a new process ID. It receives a value of 0 as the return value from fork. It’s this return value which lets program code determine if it is the parent or child process once the split has taken place and respond in whatever manner is appropriate for that specific application. vfork is a legacy item. It’s similar to fork except it guarantees that user memory won’t be copied. This is intended to improve performance and efficiency. When I say fork makes a duplicate, I really mean it; everything in the child processes space is exactly like the original with the exception of the fork return code. All the memory contents within the process space it was shoehorned into are duplicated. On the one hand this is useful from a programming point of view, if the child process must draw on the app’s history and current state to perform its duties. Yet, on the other hand, if the child process doesn’t really need to know any of this, or doesn’t care, then all that memory copying was actually wasteful. Here’s where vfork comes in; it spins off a child process but without the time-expensive memory reads and writes. The init process uses this system call when it creates all its children. There’s no need for any process to have a copy of the user state of init so the kernel developers figured a second system call like vfork would be an efficient alternative for init’s purposes and others like ftpd and inetd/xinetd. In practice, vfork is complex to implement because it makes certain demands on the child process particularly that it uses exec to invoke a command immediately and that this command does not fail. If the spawned off process fails then the results are undefined and hence unpredictable. If you check the vfork man page you’ll find some interesting notes putting it down, including that vork’s actual existence is an unfortunate spectre of the past! All modern Linux and UNIX distros use a technique called copy on write which negates the need for vfork to exist because now the regular fork system call has the efficiency gains that vfork was created to bring about. Copy on write causes the parent and child processes to share physical memory for as long as possible and only copies memory pages when one of the processes actually writes data to memory. If a child process is forked and doesn’t write any memory then you have a big win because no memory copying was required. Even if the child process modifies a small bit of memory there’s a gain because only the modified pages are duplicated. In fact, not only do you save time you also save memory because you just need one physical set of data for two processes, for as long as possible. Consider the gains this gives init and xinetd and other important system functions whose whole purpose is basically to fork and exec. The clone system call is unique to Linux and is a general purpose fork but which allows an application control over which parts of the child process will be shared with the parent. exec, mentioned above, is a fundamental system call. Or rather, it is a family of system calls and which are documented in the exec man page. Several different calls are listed there but these are all wrappers around one, execve. The purpose of execve is to execute a command, or more specifically, to transfer control of your process from one executable program to another. This is why we say init forks and execs; it makes a new child process then uses exec to call up a new program in its place, without harming the original parent process. Now, all these processes are well and good, but how can you find out just what is running on your system in a finely-grained way, with important process monitoring information. The answer is the /procfs directory which is a pseudo file system to present information about all the running processes. A user can cd into this directory and inspect files as if they were legitimate disk-based files. You can get lots of valuable information without having to resort to any further tools. Meanwhile, a program can inspect the contents with nothing more than basic open, read, write and close system calls. Each process has a subdirectory under /proc named after its process ID. So, process ID #1, init, has a directory called /proc/1 which exists for its lifetime. Additionally, a special directory called /proc/self also exists which is a link to the directory of the currently running process. Inside each directory is a set of files that give detailed information on the process footprint. Most of these are ASCII text files. Some of the more interesting and important are as follows: cmdline The command line used to invoke the program. Strings are separated by the NULL (ASCII 0) character. This is how a C program would see the argv vector. environ The processes’ environment, with string delimination as above. This is how a C program would see the envp vector. fd A directory with a symbolic link for every file descriptor open by the process. This includes disk files, sockets used for network communications and pipes for interprocess communication. Here’s where you can really get info on what your processes are doing. oom_score A text file holding the processes “out of memory” score. When Linux runs out of memory it kills processes with high scores first. stat A one-line textual representation of the process status. This is used by the ps command. status The same information as given in stat, but in a more human-friendly format. wchan Indicates just which kernel system call is causing a process to block, if it is blocking. As well as exploring this directory by yourself you can call upon the free tools in the SourceForge procps project. This is a collection of small useful utilities that make use of the proc file system. Some will be very familiar – namely ps, kill, w, top and possibly vmstat. Others will be possibly new to you like slabtop and skill. Come back next time for more! Original link: http://www.itwire.com/content/vi... |
