1 / 23

System Processes

System Processes. UNIX Chapter 13. System Process Overview. In UNIX every program runs as a process and is managed by the Kernel. Processes can be initiated either by the operating system or by users

nida
Download Presentation

System Processes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. System Processes UNIX Chapter 13

  2. System Process Overview • In UNIX every program runs as a process and is managed by the Kernel. • Processes can be initiated either by the operating system or by users • A process can start a subprocess. This creates a process hierarchy or tree similar to the file system structure with parent/child relationships. • The parent process provides an environment for the child process to run. The parent process waits in a suspended state until the child process is finished. Once the child process is completed, or terminated by a user, the parent process reassumes control and the shell prompt returns.

  3. System Process Overview • When a process is placed in the background, as in • $sort largefile& • (the ampersand at the end of the command line instructs the shell to process the sort in the background), the shell does not wait in a suspended state for the child process to finish. This is basically how multiprocessing works in UNIX.

  4. System Process Overview • Each process is assigned a unique process identification number (PID) and is used by the system to identify and track the process until it is completed. • The first two processes started when a Solaris based system is booted are sched (scheduler - process ID of zero) and init (initialization - process ID of one). These two processes manage all other processes. • Linux does not have a scheduler process but instead starts the init process (process ID of one) and various memory and kernel handlers.

  5. System Process Overview • The init process is the parent of the login program that verifies the login name and password entered. • On a successful login, the login program starts the login shell of that user. • Init, the parent process of the login shell, goes to sleep and waits for the login shell, to shut down or die when the user logs out. The parent process then wakes up and starts another login program. • The OS kernel manages the initiation and termination of all processes and allocates CPU time and memory and reallocates them when the process ends

  6. Types of Processes • Daemon - Daemons are processes that are started by the UNIX kernel and that exist for a specific purpose. For instance, the lpsched (line printer scheduler) daemon exists for the sole purpose of handling print jobs. • Parent - A process that generates another process is referred to as its parent. Every process except init has a parent process. • Child - A process that is started by another process. For example, when a user is working in a Terminal window, that terminal's PID is the parent process ID (PPID) of any commands issued. The parent process receives and displays the output from the child process and then shuts down or kills the process. • Orphan – A process whose parent terminates before it can return its output. • Zombie – A child process that does not return to the parent process with its output. Becomes lost in the system.

  7. The PS Process • The ps (process status) command is used to list the processes currently running on the system. • The processes will list the name of the command or program that initiated the process and any child processes that it might have generated. Processes can be verified by issuing the ps command more than once. • Use the ps command to check the PID of the process and then shut down or kill the process if it is taking too long or has stopped. • ps – e = every process • ps –f = full info about processes on current terminal shell • ps –u (userid or processid) • tty to determine which terminal you are using • ps –t (terminal)

  8. Searching for a Process • On most systems, hundreds of processes are running, and the ps -ef listing can be quite long. To locate the name of the executable, use grep to find the PID. • The -e option displays the PID and the name of the initiating command, which allows grep to search on this information • Specific to Solaris is the pgrep command used to search for a specific process by name rather than by PID number.

  9. Parent and Child Relationships • To terminate a program or release a hung Terminal window, it might not be enough to kill the PID that is associated with the unresponsive application. It may be necessary to kill the parent of that process and, on rare occasions, even the parent of the parent. • Killing a parent process will kill all child processes generated by the parent process.

  10. Parent and Child Relationships • The sleep suspends script execution for the specified duration, often executed in the backgroud. Sleep 500& • The sleep process has a PID of 785, and its PPID is 742, which is the PID of the C Shell (csh). If the user terminates PID 742, they also will terminate 785. If the user terminates the PID of the Korn shell (ksh), which is 689, they will terminate all processes initiated from that shell including the terminal window itself. • Linux supports the GNU long options variations of the ps command where options are preceded by two dashes. A useful option in RedHat Linux is the ps --forest command which displays a hierarchical relationship between parent and child processes

  11. Signals and the Kill Command • Signals are interrupts that are generated by the kernel and other processes. Signals are used to terminate, suspend, and continue processes. • A signal is sent to a process via another process (child to parent), or by kernel. • Each signal is associated with a number and a name. • SIHGP - Hangup • SIGIT - Interrupt • SIGQUIT – Quit • SIGKILL – Definite kill 15 SIGTERM – Software termination

  12. Signals and the Kill Command • Background processes, can be killed by using either the process id or the job id command. • The job command lists all jobs running in the background and the job ids. • Soft kill - If the kill command is used without specifying a signal, signal 15 (SIGTERM) is sent to the process with the specified PID number. It is best to use a soft kill on a process, if possible, because it closes files properly and usually terminates the process or processes properly.   

  13. Signals and the Kill Command • Sure Kill –It is necessary for killing shells and processes that will not respond to any other signal to terminate. • $kill -9 PID# • For processes other than shells, use the kill -9 (SIGKILL) command as a last resort. The kill -9 command is an abrupt method and does not allow for proper process termination. 

  14. Signals and the Kill Command • A user can terminate only their own processes. • If multiple windows are open on a user's desktop, the output of the ps command will show pts/# under the TTY heading for every window open. • A pseudoterminal (pts) is the device name given to windows and remote login sessions. • Each window the user opens after logging in gets a new pts#. ps -u login-ID or UID

  15. Signals and the Kill Command •  The pkill command is specific to Solaris and works exactly like the pgrep command. However, the pkill command terminates the process by matching the command name (CMD) of the process or processes • $pkill CMD name or killall [-i] CMD name (Linux)  • Caution should be used with the pkill and killall commands. The pkill and killall commands will kill all processes running with the command name the user specified. In addition, the killall command on some versions of UNIX works very differently from the Linux killall command.

  16. Running Commands Unattended • To run jobs in the background or off hours so you don’t tie up your screen, use the following commands: • cron – system scheduler • at - ad hoc jobs • & - quick job now in the background • nohup – run commands in the background, and log off, without affecting the process

  17. Background and Foreground Processes • UNIX is a multitasking OS • Foreground Processes Communication between the user and the shell happens interactively, one task at a time. • Background Processes – Programs that are run simultaneously run in the background or in a different terminal. • For example, starting Netscape from a Terminal window locks the window because the Terminal shell is the parent process of the Netscape program running in the foreground. As soon as Netscape is exited, the shell prompt returns. Typing netscape& will start Netscape as a background task and the shell prompt would return to the Terminal window, allowing the student to continue working.

  18. Controlling Background and Foreground Processes • Job control gives the capability to move a job or process between background and foreground, and manage them.

  19. Foreground and Background • Note that the number in the square brackets ([x]) is the job number. • The job preceded by a plus sign (+) is the current job and can be manipulated with fg (foreground) or bg (background) without specifying the job number. • Processes are terminated at logoff. • The nohup (no hang up) command should be used to enable a background job to complete even after logging off. For example, the command line $nohup sort customerids > custfile & followed by logging off allows the sort to continue. • After logging back on, the student could view the custfile for the results of the sort command.

  20. The AT process • The at command enables programs, commands, or shell scripts to run once only, at some future date. • Enter the at command followed by a time specification, where the time specification could be: $at 10:30am today, $at midnight, $at 12:01 1 Jan 2002, and so on. • An at job number is assigned to track the at job. Use the atq command to view the at job queue. Use the atrm [at job#] command to remove a scheduled job. • To run a script file at a specified time, use the command $at [time spec] [script file name]. For example, $at midnight whoison would run the whoison shell script that runs the who command to see what users are accessing the system at midnight and then would redirect the output to a file to be viewed in the morning

  21. CRON • Cron is the system’s main scheduler for running jobs or tasks unattended. A command called crontab allows the user to submit, edit or delete entries to cron. A crontab file is a user file that holds scheduling information. Cron is controlled by a set of files called “crontab”. • The utility allows a user to schedule a command or program to run at scheduled intervals.

  22. crontab utility • By default, in Solaris a user can edit their own crontab file where as on some other UNIX systems only the superuser will have a crontab file. • Each crontab entry in the crontab file consists of six fields separated by spaces or tabs. For example: 0 17 * * 5 /usr/bin/banner "Weekend Is Here!" > /dev/console 

  23. crontab utility • To edit the crontab file use the crontab -e (edit) command. • To list the entries in the student's crontab file use the command crontab -l (list). To delete the crontab file use the crontab -r (remove) command • The cron daemon is started when the system boots and checks all user crontab files once every minute for commands to run at that time. • To find the directory location for any command or other file on a Solaris or Linux computer, enter the command whereis followed by the name of the command or the

More Related