The numbers between `[]` are the **job ID** numbers and the four digit ones are the **process ID** numbers, or **PID**.
When using the `jobs` command you can sue the job ID to reference a particular job.
For example, run `sleep 30 & sleep 60 & sleep 90 &` and observe the output.
Next run the `jobs` command and not the more verbose output.
All three jobs are **running** and will terminate one by one.
We can bring back a process to the foreground, so we can interact with it from **STDIN**, by running the `fg` command.
If we only have one process running it will bring back this single process but you can choose which one to bring to the foreground by specifying the job ID as such `fg %2` or `fg %3`.
**Can you tell me what the `+` and `-` mean in the jobs list?**
Now, how can we gain control of our terminal again?
Observe the following output:
```
➜ ~ sleep 30 & sleep 60 & sleep 90 &
[1] 13207
[2] 13208
[3] 13209
➜ ~ fg %3
[3] - 13209 running sleep 90
^Z
[3] + 13209 suspended sleep 90
➜ ~ jobs
[1] running sleep 30
[2] - running sleep 60
[3] + suspended sleep 90
➜ ~
```
First we create three jobs that are sent to the background.
Next we bring job ID number 3 back to the foreground.
We send the **suspend** signal to this job by pressing CTRL-Z.
Note the output from `jobs` which now notes two running jobs and one suspended.
This brings us to **signals**.
### Signals
We use signals all the time without realizing it.
The most common signal we have used is the **SIGINT** that we send when pressing **CTRL-C** on a running process.
A second one most of you know by know is CTRL-Z to suspend a running job.
To see all key combination and their signals we can run the `stty -a` command.
Contrary to `jobs`, `kill` uses the **PID** numbers to reference running processes.
The PID of a process is shown when you launch it, or you can inspect the PID of all your jobs by executing `jobs -l`.
To demonstrate how to send signals I advise you to run a few long running sleep commands as follows: `sleep 32234 & sleep 324234 & sleep 72552 & sleep 453445 & sleep 96986996 &`
You can now send signals to these processes with the following syntax `kill -$signal_to_send $PID` where `$signal_to_send` is the signal and `$PID` is the process ID.
The information above is already quite interesting but we can add or remove columns to the output by using the `o` argument as follows.
Note that each process has a **unique** PID but they all share the same PPID (parent process ID).
Or do they?
Why does the first line, in my case `zsh` have a different PPID?
```
➜ ~ ps o pid,ppid,cmd
PID PPID CMD
13510 13509 -zsh
14164 13510 sleep 32234
14165 13510 sleep 324234
14166 13510 sleep 72552
14167 13510 sleep 453445
14168 13510 sleep 96986996
14199 13510 ps o pid,ppid,cmd
➜ ~
```
The list of available columns can be found in the `man ps` pages in the **STANDARD FORMAT SPECIFIERS** section (around line 500).
We can specify a specific process with the `-p $PID` argument.
```
➜ ~ ps o pid,ppid,cmd
PID PPID CMD
14466 14465 -zsh
14640 14466 tmux
14643 14642 -zsh
14681 14643 ps o pid,ppid,cmd
➜ ~ ps o pid,ppid,cmd -p 14643
PID PPID CMD
14643 14642 -zsh
➜ ~
```
Now in this shell I can start a few specific background jobs, simulated with `sleep`.
```
➜ ~ sleep 1111 & sleep 2222 & sleep 3333 &
[1] 14697
[2] 14698
[3] 14699
➜ ~ ps o pid,ppid,cmd
PID PPID CMD
14466 14465 -zsh
14640 14466 tmux
14643 14642 -zsh
14697 14643 sleep 1111
14698 14643 sleep 2222
14699 14643 sleep 3333
14702 14643 ps o pid,ppid,cmd
➜ ~
```
If I now `disown` a specific job ID, or all with the `-a` flag the processes will not be dependent on the parent's existance.
A quick `ps o pid,ppid,cmd` will still show the PPID as parent *but* when you close the parent shell and inspect the specific PID of the disowned process you'll see it's now owned by a *different* parent.
I know it sounds complicated but I urge you to test this all out in a few shells.
The practice will explain it a lot better than some codeblocks.
```
➜ ~ ps o pid,ppid,cmd -p 14698
PID PPID CMD
14698 1 sleep 2222
➜ ~
```
Now why is the process only changing parent once the original parent terminates?
I'm asking you to look for an answer online but the solution can be found the realm of *signals*, especially the *hang up* [signal](https://en.wikipedia.org/wiki/SIGHUP).
## Nohup
TODO
## Zombie processes
Yes, there are such things as zombie processes.
Learning how to create them is a bit out of our scope but I highly advise you to read up a bit on [what](https://en.wikipedia.org/wiki/Zombie_process) they are and [how](https://www.howtogeek.com/701971/how-to-kill-zombie-processes-on-linux/) to deal with them.
## Process priorities
Life is all about setting priorities and while Linux is very good at managing it's CPU time all by itself, sometimes we know better.
We've seen the priorities before in `htop` in the `NI` column but we can view them as well via `ps o nice`.
A more detailed command would be `ps o nice,pid,ppid,args` which for my laptop returns the following:
I would like you to try and set a very *not-nice* value for a `ping` or `sleep` process?
You can probably guess but it won't work.
Why do you think this is?
### Renice
Nice values are not that practical if we need to set them before we start a process no?
That's where the `renice` program comes into play.
It allows us to change the nice value of a running process with a very simple syntax.
I would advise you to use `sudo` whenchanging the nice values because otherwise you'll constantly run into either `operation not permitted` or `permission denied` errors.
```
➜ ~ git:(master) ✗ ping 8.8.8.8 > /dev/null &
[1] 16877
➜ ~ git:(master) ✗ ps o nice,pid,args -p 16877
NI PID COMMAND
5 16877 ping 8.8.8.8
➜ ~ git:(master) ✗ sudo renice -n 20 -p 16877
16877 (process ID) old priority 5, new priority 19
➜ ~ git:(master) ✗
```
## /proc virtual filesystem
TODO
## Exercises
To help you understand what happens to running and stopped processes I made a few python scripts you can download below.
Run them either with `python3 $SCRIPT_NAME` or `./$SCRIPT_NAME`.
