#compsci ## ps output ``` $ ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND timothy 29217 0.0 0.0 11916 4560 pts/21 S+ 08:15 0:00 pine root 29505 0.0 0.0 38196 2728 ? Ss Mar07 0:00 sshd: can [priv] can 29529 0.0 0.0 38332 1904 ? S Mar07 0:00 sshd: can@notty ``` %CPU - CPU time used divided by the time the process has been running %MEM - ratio of the process' resident set size to the physical memory of the machine VSZ - virtual memory usage of the entire process (RSS, swapped, other shit) (in kB) RSS - resident set size, the non-swapped physical memory that a task has used (in kB) STAT - multicharacter process state START - starting time or date of the process TIME - cumulative CPU time ## Process creation When a new process is created, an existing process basically clones itself using the **fork** system call. This child process takes a new PID, while its progenitor has something called PPID (parent PID). Afterwards, the new process can either continue to run the same program as its parent or launch another one by using the system call **execve**, which destroys the memory management that the kernel put into place for that process and sets up new ones for the new program. You can see the PPIDs using the $ ps -l command. When the system boots up, the kernel creates a process called init, which has a PID of 1. This process can't be terminated unless the system shuts down. ## Process termination A process can terminate using the **exit** system call, which involves sending the kernel a termination status - basically why it wants to terminate. Then the parent process has to acknowledge the termination by using the **wait** system call, which checks the termination status. Then the termination is complete. If a parent process dies before its child process, the kernel knows it's not gonna get a wait call, so it makes these child processes **orphans** and makes init perform the wait system call so these process could die. If a child has terminated but its parent hasn't yet send the wait call, the kernel turns the child process into a zombie process. This means that resources of this process have been fred up, but it is still in the process table. Eventually the parent process calls the wait call, so the zombie disappears - the "reaping". If the parent doesn't do so, the init process will. ## Signals A signal is a notification to a process that something has happened. Common signals: SIGHUP or 1: Hangup (sent to a process when the controlling terminal is closed. For example, if you closed a terminal window that had a process running in it, you would get a SIGHUP signal. So basically you've been hung up on) SIGINT or 2: Interrupt (Is an interrupt signal, so you can use Ctrl-C and the system will try to gracefully kill the process) SIGKILL or 9: Kill (Kill the process, kill it with fire, doesn't do any cleanup) SIGSEGV or 11: Segmentation fault SIGTERM or 15: Software termination (Kill the process, but allow it to do some cleanup first) SIGSTOP or STOP: Stop (Stop/suspend a process) Numbers could vary so the signals are usu referred to by their names. ## Niceness Niceness is a process' property that determines its priority. A high number means the process is nice and will have a lower priority, a low number (including <0) means the process is not nice and will have a higher priority. To change the default niceness of a process, use nice: $ nice -n 5 apt upgrade To change the niceness of a current process, use renice: $ renice 10 -p 1234 ## Process states R - running or runnable (latter - waiting for the CPU to process it) S - interruptible sleep (waiting for an event to complete) I - idle kernel thread D - uninterruptible sleep (processes that can't be killed or interrupted with a signal, reboot or fix the issue) Z - zombie T - stopped ## /proc In Linux, everything is a file, including processes, which are stored in /proc. You could see some interesting info about a process if you cat /proc/%process%/status ## Job control Appending an & to the command will run it in the background. You can see background jobs by typing: $ jobs To send a process you have already started into the background, suspend it (Ctrl+Z), then run the bg command. To move a process back into the foreground, use: $ fg %!number! E.g $ fg %1 You can also kill background jobs: $ kill %1 ## Tracking processes ``` top - 18:06:26 up 6 days, 4:07, 2 users, load average: 0.92, 0.62, 0.59 Tasks: 389 total, 1 running, 387 sleeping, 0 stopped, 1 zombie %Cpu(s): 1.8 us, 0.4 sy, 0.0 ni, 97.6 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 32870888 total, 27467976 used, 5402912 free, 518808 buffers KiB Swap: 33480700 total, 39892 used, 33440808 free. 19454152 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6675 patty 20 0 1731472 520960 30876 S 8.3 1.6 160:24.79 chrome 6926 patty 20 0 935888 163456 25576 S 4.3 0.5 5:28.13 chrome ``` 1st line (uptime + load average) Load average - represent the average CPU load in 1, 5, and 15 minute intervals. CPU load = average numbver of processes that are waiting to be executed by the CPU.s 2nd line: tasks info 3rd line: CPU information 1. us - user CPU time (percentage of CPU time spent running users' processes that aren't niced) 2. sy: system CPU time - percentage of CPU time spent running the kernel and kernel processes 3. ni: nice CPU time - percentage of CPU time spent running niced processes 4. id: CPU idle time - percentage of CPU time that is spent idle 5. wa: I/O wait - percentage of CPU time that is spent waiting for I/O 6. hi: hardware interrupts - percentage of CPU time spent serving hardware interrupts 7. si: software interrupts - ditto, but for software interrupts 8. st steal time - the percentage of CPU time that was stolen from you for other tasks if you are running virtual machines 4th & 5th lines: memory and swap usage Processes list: 1. PID 2. user that is the owner 3. prioritiy 4. nicenss 5. virtual memory used 6. physical memory used 7. shared memory of hte process 8. status 9. %CPU 10. %MEM 11. total time of activity of this process 12. name of the process You can also specify a process ID if you just want to track certain processes: $ top -p %PID% ## lsof and fuser lsof lets you see a list of all the open files and their associated processes $ lsof %directory% Another way to track a process is the fuser command, which will show you the info about a process that's using a file: $ fuser -v %directory% ## Process threads Processes operate with their own isolated systeme resources; however, threads can share these resources among each other easily, making it easier for them to communicate between each other. To view process threads, use $ ps m. Underneath the processes are their threads (denoted by a --). If there's more than one thread, it's a multithreaded process ## I/O monitoring $ iostat - monitor CPU/disk usage 1st part: CPU info %user - percentage of CPU utilization that occured at the user level (apps) %nice - ditto but for niced apps %system - percentage of CPU util. that occured at the kernel level %iowait - percentage of time spent waiting for disk I/O request %steal - percentage of time spent when CPUs were idle cause of vms %idle - idle 2nd part: disk info tps - transfers per second to a device other parts are pretty clear on their own ## Memory monitoring $ vmstat ## sar sar is a tool that is used to do historical analysis on your system Enable it in /etc/default/sysstat Details from the start of the day: $ sudo sar -q Details of memory usage from the start of the day $ sudo sar -r Details of CPU usage $ sudo sar -P Using logs: $ sar -q /var/log/sysstat/sa%daynumber%