Cosc 4750

1. Processes Cosc 4750

2. Processes • All Processes have • PID (Process ID) • PPID (Parent Process ID) • UID (User ID) and EUID (Effective UID) • GID (Group ID) and EGID (Effective GID) • Niceness • It scheduling priority (range: -20 to +19) • Control Terminal • The terminal it was launched from, where standard output goes

3. Process “life cycle” • Each process is created by the Parent process coping itself with a fork system call • The new child process then uses the one of the exec commands start the run the program. • The child then runs to completion (or killed) and the parent always receives an exit code • 0 indicates normal or “successful” termination • The parent process must wait for the exit code or if the child process is “back grounded”, then acknowledge the child process finished.

4. Ultimate parent process • The init process is the “Parent” of all processes. • Should a parent process terminate before a child process, init becomes the parent to the orphaned process • It will receive and acknowledge the child process exit code.

5. Signaling a process • If a process is running the foreground • <control-c> will end the process • <control-z> suspends the process • In the background (or if root) • kill –9 <PID> or kill –KILL <PID> • Will terminate the process (almost always) • kill –1 <PID> or kill –HUP <PID> • will tell system processes to reread it’s config file otherwise, the process dies. • xkill (typed in shell), then click on a window • Will terminate the running window.

6. Other signals: • -2 or –INT will interrupt, like <control-c>, if not caught, then process dies • -3 or –QUIT will “quit” the process with a core dump • -BUS causes a bus error and the process dies with a core dump • -SEGV causes a Segmentation fault, the process dies with a core dump • -WINCH causes an editor (like vi) to reconfigure itself.

7. Kill –STOP <PID> suspends the process. • Kill –CONT <PID> will continue a suspended process • kill –TERM <PID> asks the process to terminate, but the process may ignore the request • There are other non-standard signals • man 7 signal • Will show you all the signals and their meaning.

8. Process State • run: The process is executing or can run. • run/X: process is executing on processor X • Sleep: The process is waiting for a resource • Zombie/Defunct: process is trying to die • stop: the process is suspended

9. Listing processes • ps –ef lists: • UID, PID, PPID, C, STIME, TTY, TIME, COMD • C=CPU use/scheduling info • STIME=Time the process was started • TTY=Control terminal • TIME=CPU time consumed • COMD= Command and arguments • ps –efaux • Lists the above and much more.

10. TOP • lists process by CPU usage • adds to the nice, size, rss, state, %cpu, and %Mem • nice=is the priority the process is running at • state= the “state” the process is in • size=how big the program is • rss=how much memory it is using • %cpu=The percent of the cpu time it is using • %mem=The percent of memory it is using

11. Nice & Renice • Sets the priority of a process • Normally a new process uses the priority of it’s parent process • Range between -20 and +19 • Highest priority is -20 • Lowest is +19 • nice +5 app • starts the app at +5 priority, normally priority 5

12. Renice 19 <pid> • Sets the priority to 19 on that process • Renice 19 –u <user> • Sets the priority of all that users process to 19

13. Periodic Processes • Using cron to schedule commands to be run • used to roll logs • backups • System filesystem clean up • any process you need to run every so often to complete a task.

14. example: • 0 0 * * 5 /usr/local/bin/perl /backups/backup • Uses a set of time fields and then a command • minute hour day month weekday command • minute= 0-59 • hour= 0-23 • day=1-31 • month=1-12 • weekday=0-6 (Where 0=Sunday)

15. 0 0 * * 5 /usr/local/bin/perl /backups/backup • * can be used in fields you don’t need/ not worried about • So the example, runs at Midnight, Friday night no matter, the day or month • 45 10 * * 1-5 find / -name core –exec rm –f {} \; • At 10:45am, Monday through Friday, removes any core file on the system.

16. 45 10,22 * * 1-3,5 find / -name core –exec rm –f {} \; • At 10:45am and 10:45pm, Monday through Wednesday and friday, remove any core file on the system. 0,5,10,15,20,25,30,35,40,45,50,55 * * * /bin/getneworkinfo.pl • Every 5 minutes run the program /bin/getnetworkinfo.pl

17. Crontab commands • crontab <filename> • Use <filename> as the cron file • crontab –l • lists cron file • crontab –r removes the cron file • crontab –e edit cron file with default editor

18. Devices and Drivers

19. Serial Devices • Serial Device files (Redhat) • /dev/cua[0,1,2,3] • (historical, for compatibly, but most systems no longer create them automatically.) • /dev/ttyS[0,1,2,3] • ttyS0 does not always mean Com port 1/A

20. Set port settings • setserial –g /dev/ttyS0 • Displays the software settings for that serial port • setserial /dev/ttys1 port 0x02f8 irq 3 • changes the software settings • Does not change hardware settings, those must be changed in the bios.

21. Terminals devices • A user enters a login name at a getty prompt • getty executes the login program • login requests a password and validates it with /etc/passwd • (at this point it very vendor specific and shell specific) • login prints the message of the day /etc/motd • login sets up the TERM environment variables and executes the shell • Shell then executes the appropriate startup files • Shell then waits for your input.

22. Redhat and tcsh • getty gets the login name, then execs login for the password with the /etc/passwd • login display the motd • loginexecs tcsh (specified in the passwd file) • tcsh then sources /etc/csh.login, /etc/csh.cshrc, ~user/.cshrc, and ~user/.login • environment variables are setup in /etc/csh.login and /etc/csh.login. User specified variables from .cshrc and .login (note: .login is not always sourced)

23. By default csh.cshrc only setups on the prompt • csh.login sets the following variables • PATH, umask, HOSTNAME, history, and other variables for programs like kerberos • Bash uses different files, /etc/profile, /etc/bashrc, ~user/.profile, ~user/.bash_profile, and ~user/.bash_login with similar results.

24. login and tty • Every login is assigned to a tty. • There is no common naming convention for the login tty you use. • Redhat uses tty[0-12] and pts/X • SGI uses ttydX for console and ttyqX for most other logins • Sun uses pts/X and console (for console logins)

25. Where do getty’s come from? • getty is exec’d by the init process, based on the configuration from the /etc/inittab file • Redhat default is 6 getty (called mingetty) • Each getty gets one tty[1-6] • When the last foreground process with tty1 (for example) exits/dies, then init creates a new mingetty process for tty1

26. configuring your tty • stty allows you to configure your tty/ terminal. • stty intr ^C kill ^U erase ^H • setups up the terminal where <control-c> interrupts, <control-u> kills, and the “backspace” key is <control-h> • stty and stty –a • display the setting for your terminal. • tset automatically initializes your terminal to the settings for the TERM variable. • reset: resets you terminal back to “sane” settings • stty sane is the same as reset

27. Other • parallel port(s) • parallel ports can be configured similarly • USB • “current” linux distro’s support USB. • The USB device is “mounted” into the filesystem. • Such camera’s, flash drives, etc… • For mice, and other devices without a filesystem, only a device file is created.

28. inittab file • Determines how many console logins a linux system starts up • Normally, 6 console login prompts and the 7th is for the X-windows system • /etc/inittab works with the run-level • id:run-level:action:process so for the console • 1:2345:respawn:/sbin/mgetty tty1 • 2:2345:respawn:/sbin/mgetty tty2 • 3:2345:respawn:/sbin/mgetty tty3

29. More actions • ctrlaltdel runs in response to <cntrl><alt><del> • Once start the process once • respawn start the process, then when it exits, spawn a new process • powerfail runs when the system gets a power fail signal

30. Console logins • Some editors and cat’ing binary files can screw up your console (telnet, xterm, etc) • To fix these problems you can use one of two commands • sane Reset console settings to default • reset Reset console settings to default and clear buffers

31. You can also use the command stty to set terminal settings • stty intr ^c erase ^? • Sets the <cntrl-c> to break current process • Sets the the backspace key to erase one character of input • stty –a • shows you all the settings for your term. • You can test varing things, if it does work, use the sane command to put back to default. • Note: Fedora logins do most of this for you.

32. Adding disks • install the hardware • make sure properly connects and jumper’d (if needed) • make sure the hardware is recognized by the “bios” • UNIX will automatically create device files for recognized hardware • partition the drive as need (see dmesg for dev name) • fdisk or others example: fdisk /dev/hdb • Make the filesystem (like formating in windows) • mke2fs for ext2 fs or mke3fs for ext3 • mke3fs /dev/hdb1

33. Standard filesystem • create an empty directory to mount it • mount the partition • add the mount to the fstab file for automatic mounting on boot up. • /dev/sdb1 /somedir ext3 defaults 0 0 • See the boot for a detailed step by step installation guide (software only)

34. swap partitions • add swap partition to the swap space swapon /dev/hda2 (redhat example) • add partition the /etc/fstab file /dev/hda2 swap swap defaults 0 0

35. check/repairing filesystems • fsck (linux and Sun) will check and attempt to repair filesystems • fsck –p /dev/hdaX is run by default on boot when the filesystem was not cleanly shutdown • fails on serious errors and asks for help • fsck /dev/hdaX will repair most errors, but needs user help.

36. The Kernel • Linux kernel • 2.6.9-55.0.6 is the current kernel (Redhat anyway) • The first two numbers • even numbered kernels are production • odd numbered kernels are beta/test • The next major release of the kernel will be 2.8.0 (sometime in the future) • next minor release (might be) 2.6.10

37. Building kernels • We used spend a great deal of time on building kernels for all major vendors with drivers. Chapter 27 will give you some information • With rpm, at least time is now spent on it. • Using rpmbuild we can rpm do must of the work. Look for the doc directory in /usr/src/redhat/BUILD/kernel-* for information on drivers and components. • lsmod displays loaded kernel modules • insmod loads manually a module into the kernel • at boot, configured in the /etc/conf.modules

38. Q A &