There are a number of ways to get to root access, some of them not entirely intuitive.  For example, what's the difference between sudo su and sudo -i?  How about su - ?

Root can be used in a variety of ways, so there are a variety of ways to get root access.

One thing to consider when obtaining root is the environment that you need to do what you want to do.  If you just want to run a command, you can just use sudo before the command that requires root privileges, then enter your (not the root) password.  This requires that you be part of the group that controls sudo access.  In some distributions, this is the wheel group, in some it's sudo.  To get access, someone with root privileges has to run something like usermod -aG wheel username.  

Let's break that command down a bit:

1. usermod is the command that allows you to modify a user
2. -aG means append/add the user to the supplementary group named next
3. wheel is the name of the group that determines sudo access
4. username is the username of the user who will be getting sudo access

You could also drop a file with the user name into /etc/sudoers.d:

username	ALL=(ALL) ALL

How do you know what groups you're part of?  Simple - just use the groups command or the id command.

Now that the basics are out of the way, let's talk about the different base commands.

1. su : Surprise!  This does NOT stand for "super user", it stands for "SUBSTITUTE user".  If you enter it with no arguments, the assumption is that you want to switch to the root user.  Requires the root password.
   NOTE: $HOME and $PATH will remain that of the current user, not the root user.
2. su - : Functionally the same as su -l(login). This command does log you in as the root user, with the root user's $HOME, $PATH and id.  Requires the root password.
3. sudo su - : This seems like it would do the same thing as su -, but it doesn't.  Adding sudo before the command tells the shell to use the root privileges of the current user, and as such, only requires the password of the current user, NOT the root user.  This gives you a root login shell, and your $HOME, $PATH and id become that of the root user.  This only works if you have ALREADY been given root privileges and are part of the sudo group.
4. sudo -i : Functionally the same as sudo su -.

And now you know a little bit more about the routes to root!

Sometimes processes crash, or use too many resources, or just need to be gracefully shut down.  In this post, I'll cover the following:

• nice
• renice
• kill
• pkill

Let's talk about killing first. There are actually two different commands with "kill" in them, and they do different things.  There are also different ways of killing processes, and some of them aren't even very murderey!

The first thing we should cover is how you can even tell if a process is causing problems - it's not always as easy as something becoming unresponsive.  It could be that a process is using too much memory, or too many CPU cycles - but how do you determine that?  If you're even vaguely familiar with Windows, you'll know about the Task Manager.  Linux has something similar, called top.  Just type "top" in a shell and you'll see something like this:

There's a lot to unpack here, but we're only going to focus on two areas right now - the first line with the text load average: 0.28, 1.05, 1.20, and the %CPU column.  

The load average line shows a running average of system load over 1 minute, 5 minutes and 15 minutes.  These numbers will change, and by watching them for a moment, you'll be able to tell if your system's load is increasing or decreasing.  It's important to note that this information is for all cores COMBINED, so to determine the real load on your system, you need to divide the number you're interested in (say, the 15 minute figure of 1.20) by the number of cores in your system.  My system has 6 cores, so I would divide 1.20 by 6, which is .20 - that means that over the last 15 minutes, my system has been running at 20% load.  Which isn't bad at all!  

Now let's assume that your system has suddenly slowed down.  You open top and see the following:

Whoa!  We've got a load averages of 9.20, 4.28 and 2.18 - that's 154% over 1 minute, 71% over 5 minutes, and 36% over 15 minutes.  So we can tell just from looking at these numbers that something started hammering the system within the last 5 minutes or so. And if we look below, we can see that a process called ghb is using 482.4% of the CPU! That's actually Handbrake, which was busy converting a video, so that's kind of to be expected, since video conversion is a resource-intensive process.

But what if I want to do more than just sit back and let Handbrake bog my system down until it's finished?  That's where renice comes in!

Every process in Linux has a "nice" value.  The nice value determines the priority of the process, and the priority determines how much of the system's resources the process is allowed to use.  In top, the nice value is in the "NI" column, and we can see that Handbrake has a nice value of 0, which is essentially neutral, and which was also assigned automatically by the system.  Nice values go from -20, which is the LEAST nice, to 19, which is the MOST nice.  

Think of the nice value in terms of people (processes) standing in line to get into a concert.  Let's assume three different scenarios:

1. Scott is standing at about the halfway point of the line.  Scott has a nice value of 0 - he's not at the front of the line, but he's not at the back, either.
2. Crispin starts out right behind Scott, but he keeps letting people get in line in front of him, which eventually puts him at the back of the line.  Crispin has a nice value of 19 - he's the nicest it's possible to be.
3. Steve arrives right before they're about ready to let people in and he cuts the line right at the front.  Steve has a nice value of -20 - not nice at all!

Using the magic of renice, we can move these processes/people around.  Before we do that, however, it's important to know that regular users have fewer permissions than the root user when it comes to adjusting priorities, so a regular user can only make a process MORE nice, not LESS.  Only the root user (or someone who has permission to sudo) can give a process more resources/make it less nice.

So let's assume that Steve is Handbrake/ghb, and type renice -n 10 456911, where 456911 is the Handbrake's process id (PID - see the left column in top above), and -n 10 tells the system what the new nice value should be.  Since Handbrake started at a nice value of 0 and was using 482% of available system resources, this new nice value of 10 will cause it to use far fewer resources.  

However, what if I want to make more resources available to Scott (Joplin), now that Scott (Handbrake) isn't using so much?  I would need to use sudo, because giving permission to use more resources requires root privileges.  So I would type something like sudo renice -n -10 273996(Joplin's PID - see top above).  This would let Joplin run smoother, as it would have access to more CPU and memory than it did before, and significantly more than Steve/Handbrake.  That's what you get for cutting, Steve!

We're not done with Steve yet, though!  We still need to talk about kill and pkill.  Now let's assume that Steve doesn't like that he had to go almost to the back of the line, and he starts faking a seizure in an attempt to make people feel sorry for him so he can get back to the front of the line.  In Linux, this means that Handbrake starts to hang.  Oh no!  Here's where it gets interesting, though, because we've got a License to (p)Kill (I'm so sorry).

There are technically 31 different kill signals we could send, but I'm not going to cover them all here.  It's enough to know that each kill signal has a number, and the number is what you use to tell the system exactly how you want to kill a process.  By default, if you don't use a number at all, the system will send signal 15 (SIGTERM), which will basically tell a process to shut itself down gracefully if it can, much like short-pressing the power button on your computer or laptop - when you do that, stuff is going to try to shut down in a way that won't cause issues like data loss.  HOWEVER, if the process doesn't shut down, and we need it to just die now, immediately, don't try to save anything, just die, we would use signal 9 (SIGKILL), which causes immediate death.  To do this, you simply type kill -9 ghb and Handbrake/Steve will die as soon as you hit enter.
NOTE: You can't kill processes owned by others without root privileges.

Alternatively, if we just want to PAUSE Handbrake while we get some other stuff done, we could use kill signal 19 (SIGSTOP), which will effectively suspend a process, and when we're ready for it to use more resources, we could use signal 18 (SIGCONT), which will unpause/continue the process.  So sometimes, a process might only be MOSTLY dead, in a state of suspension, waiting for the true love's kiss of that sweet, sweet signal 18.

These signals aren't just for you, the system uses them as well.  For example, if your browser crashes due to an invalid memory reference (SIGSEGV), that's one of the kill signals that will automatically generate a core dump, so you'd be able to check the logs and hopefully determine why the process crashed.

Sometimes you'll have processes running that have the same command name.  Browsers do this a lot.  If you take a look at the top example above you'll see multiple instances of "brave" in the command column.  If I wanted to kill all processes that share the same command name, I would use the killall command: killall brave and the system would send a kill -15 signal to those processes.  If that doesn't work, you could send signal 9 like this: killall -9 brave.

killall leads us nicely to the last command I wanted to cover: pkill.  Like killall, pkill can be used to kill multiple processes, but it also includes advanced features like being able to kill processes based on the owning user, the owning group, the child processes of a parent process, or processes running on a specific terminal.

So if we wanted to terminate all of Steve's processes, and ONLY Steve's, we could do this: pkill -U steve. Or, if we know that Steve is logged in to the same server you're on, and is working in a shell session in tty6, we (as root) could terminate his shell by using this pkill command: pkill -t tty6.  This will send signal 15 to his shell and all processes in it, and he'd be logged out.

That's what you get for cutting in line, Steve!

elif is a portmanteau consisting of the words "else" and "if".  In bash (and Python), it's a way to test multiple statements before closing a loop, as opposed to the single statement test provided by else.  If a typical if/then construct uses an if/then/else format, elif allows for if/then/elif/then/else.

Here is a simple example that will try to start mysql if mariadb is active on the system,  psql if postgresql is active on the system. Below the example is a breakdown of what each line does:

[user@host ~]$ systemctl is-active mariadb > /dev/null 2>&1 
MARIADB_ACTIVE=$? 
[user@host ~]$ systemctl is-active postgresql > /dev/null 2>&1 
POSTGRESQL_ACTIVE=$? 
[user@host ~]$ if [ "$MARIADB_ACTIVE" -eq 0 ]; then 
> mysql 
> elif [ "$POSTGRESQL_ACTIVE" -eq 0 ]; then 
> psql 
> else 
> echo "Nuts, all outta databases here!" 
> fi

1. This line asks systemctl to check if the mariadb service is-active, and to send any output (error or otherwise) to /dev/null, or nowhere.
   Fun Fact: 2>&1 Refers to something very basic about how Unix systems operate: standard input (stdin), standard output (stdout) and standard error (stderr).
   stdin (0) is a keyboard - what you use to input information
   stdout (1) is the terminal - where output is displayed
   stderr (2) are errors.
   So 2>&1 is saying to send any errors (2) from this command to the same location as standard output (1), which in this case is /dev/null, the black hole of all Linux filesystems.
2. Set a variable called MARIADB_ACTIVE, the value of which is the result of $?, which returns exit codes from the immediately previous command.  If mariadb was active, the exit code would be 0. If it's not running, or not installed, it would be another number, between 1 and 255.  In this instance, mariadb is not installed, so the exit code is 3.
   Unfamiliar with exit codes? In bash, you can check the exit code of the previous command by typing echo $?, which will output EITHER a 0 or any other number.  If the previous command was successful, you always get a 0.  Any other number is a fail.
3. Ask systemctl to check if the postgresql service is-active and send any output (and errors) to /dev/null.
4. Set a variable called POSTGRESQL_ACTIVE with the value of the exit code $? for the command from the previous line.  In this instance, postgresql is also not installed, so the exit code is 3.
5. If/then loop using a test expression.  This is saying that if the value of the variable MARIADB_ACTIVE is equal (-eq) to 0, then
6. Run mysql if the previous line can be processed.  In this instance, the value of MARIADB_ACTIVE is 3, so the test failed, and we go to the next line:
7. elif (else if) the previous command failed, try another test expression - in this case, if the value of POSTGRESQL_ACTIVE is equal (-eq) to 0, then
8. Run psql if the test expression succeeded - it didn't, because the value of POSTGRESQL_ACTIVE is 3, so we go to the next line:
9. else - if elif failed and can't run psql on the previous line, go to the next line
10. Neither mariadb nor postgresql is installed, so we're just going to output text that says "Nuts, all outta databases around here!".
11. fi - The inverse of if and closes out the if/then loop.

Just for super geeky funsies, let's write a bash script to cover Bilbo's thought processes about taking the ring back at Rivendell, using elif:

systemctl is-active mordor-desire > /dev/null 2>&1
MORDOR_DESIRE=$?
systemctl is-active wanna-turn-into-a-gollum /dev/null 2>&1
GOLLUM_DESIRE=$?
if [ "$MORDOR_DESIRE" -eq 0 ]; then
> echo "I'm going on an adventure!"
> elif [ "$GOLLUM_DESIRE" -eq 0 ]; then
> echo "REEEEEEEEEEEEEE"
> else
> echo "I'm sorry that you must carry this burden"
> fi

Put simply, a Docker container is like a mini virtual machine.  It contains just enough to do what it needs to do, and no more.  It's also isolated from the machine it's running on, so crashing the host machine is many orders of magnitude more difficult than if the application in the container was running directly on the machine.  You can also run a LOT of them at the same time with not very many resources.  I'm currently running 22 containers on a modern 8 core server with 64 GB of RAM, and CPU usage usually doesn't exceed 3 or 4% per core, and memory usage doesn't get above 4 or 5 GB.  It also works well on older systems with less specs - I also have an ancient server in a closet running an old 4 core Athlon chip with 8 GB of RAM, and it does just fine running 20 containers.  

Let's look at an example of how docker can be useful.  Assume that you come across an application that you want to install on your Ubuntu system.  It's a document scanning program that requires Python 3. Your main Ubuntu system has Python 2 installed and can't be updated because other software already installed on the system requires that specific version to work.

It's not really practical to install two versions of Python on the same machine - you could technically do it, but it wouldn't work right without a lot of faffing around.  BUT (insert non-denominational angelic choir sounds) you managed to find the application you need in a Docker container.  This means that the author of the software you want has created a docker image in addition to providing a "bare metal" installer that installs directly on your system.

Installing the bare metal version of the software requires that you first install any dependencies that are required for the application to work.  This includes the correct version of Python and the relevant libraries, some font files, software to convert files to PDF, software to generate thumbnails, software that can scan graphics for text and convert it to editable, searchable text, a database to store all of this information, maybe some search software to enable you to search for documents, and a lot more.  You'd have to do that yourself if you want to go the bare metal route.  However, in addition to the bare-metal version, the author of the software has packaged everything the program needs to run and has put it in a single container for you - a docker image.  As long as your system can run docker images, you can install this software quickly and easily.

There are only two things you need to (optimally) run any docker container:

1. Docker Engine
2. Docker-compose

Docker Engine

So what is Docker Engine?  Very simply, Docker Engine is set of several pieces of software that allows your system to read and use docker images.  A docker image is what is provided by a developer - it contains instructions on how to build a container from the image, like a template.  If you're using Ubuntu, you can install Docker Engine by following the instructions here.  Here are the important bits of the Docker Engine:

The docker daemon (dockerd) hangs out on your system waiting for requests to do stuff, like "give me a list of all currently running containers", "stop container x", "start container y", etc.

The docker client (docker), is how you, the user, will interact with your containers.  When you type in a command like docker ps, you're telling the client to create a message for the docker daemon, telling it to list all currently running docker images.  The docker daemon hears this and executes your request.

Docker registries are where you'll find docker images.  The main docker registry is the Docker Hub.  There are others, though, like quay.io.

To create and run a docker container (without docker-compose), you would send the following as a single command (we'll assume you want to install the papermerge docker container):

docker run -d \
  --name=papermerge \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=America/New_York \
  -e REDIS_URL= `#optional` \
  -p 8000:8000 \
  -v </path/to/appdata/config>:/config \
  -v </path/to/appdata/data>:/data \
  --restart unless-stopped \
  ghcr.io/linuxserver/papermerge

Let's break this down, line-by-line.

Line 1: docker run -d \ This is the command to run a docker container - the "-d" means that it should run "detached", which is a good idea if you don't want to keep a terminal window open the entire time the container is running.  The "\" at the end of the line tells your terminal to go to the next line instead of executing the command on the current line.

Line 2: --name=papermerge \ This is simply the name of the container - you want something easy to read, especially if you have a number of containers running at the same time.

Line 3: -e PUID=1000 \ This is the ID of the user who will be running the command to execute the container.  This is the "owner" of the container.  Usually it just needs to match your usual user ID, which is typically "1000" on most flavors of Linux.  The "-e" simply means that what you're defining here is an "environment" variable.

Line 4: -e PGID=1000 \ This is the ID of the group that the container will belong to.  In Linux, pretty much everything has both an ID and a group ID.  This is the ID of the same group the user belongs to, which again is usually 1000.

Line 5: -e TZ=America/New_York \ Another environment variable!  Software often needs to know what time it is, so "TZ" stands for "Time Zone", and New York is the time zone this particular computer resides in.

Line 6: -e REDIS_URL= optional \ Redis is a kind of database - it's optional in this case, but if you want to use one for this image, it's supported!  We'll leave it alone.

Line 7: -p 8000:8000 \ "-p" here stands for "port". There are actually a few things going on here.  First of all, understand that ports are basically like "portholes" through which computers (and containers) pass data through.  

In this example, the first "8000" is the port for the host machine, and the second "8000" is the port for the container.  This format is useful because you could perhaps have something else that's already using port 8000 on your host machine, so you could define a different port here, like 8020, in which case you'd have -p 8020:8000 \.  This means that when your container is up and running, you would access it in your browser by tacking that port number to the end of the IP address of the machine the container is running on.  For example, if your computer's IP address is 192.168.1.221, you would access this container by going to 192.168.1.221:8020.  That request is then passed to port 8000 in your container.

Line 8: -v </path/to/appdata/config>:/config The "-v" here stands for "volume".  Containers by their very nature are "contained", but sometimes there is a need for part of the container to be visible outside the container.  In this instance, this container has some editable configuration files.  There are several advantages to creating a volume outside of a container.  

First, while it is possible to access the configuration file that is located within the container, doing so has two problems:

1. You'd have to use the docker exec command to get a shell for the container, and
2. Any changes made inside a docker container only last as long as the container is running - they are not persistent.  The next time the container is started, docker is going to re-create it from the image, which does not include any changes you made.

Second, creating a volume outside the container, and defining that volume when you run the container means that you can access and edit anything in that volume using your normal editor at any time.  It also means that the contents of that volume can be backed up.

Let's look at the format of this command, because it's pretty important.  It follows the same logic as the port command, in that the first part references the host computer, and the second part refers to the container.  So  instead of <path/to/appdata/config>, you would enter something like /opt/papermerge/appdata/config, which is a directory on your host system.  If this directory doesn't yet exist, docker will create it.  The second part says essentially "copy the contents of the config file (in /config in the container) to /opt/papermerge/appdata/config, AND mirror any changes made to the files in /opt/papermerge/appdata/config INTO /config in the container.

The creator of the image determines what goes in the config folder, you don't have to do anything except modify whatever is in there, if you want/need to.

Line 9: -v </path/to/appdata/data>:/data Same as the /config directory, but for whatever goes in a data directory for this particular image.

Line 10: --restart unless-stopped If you don't add this line, the docker container will not be restarted when your system is rebooted.  Another alternative here is "always".

Line 11: ghcr.io/linuxserver/papermerge This is the actual location of the image in a repository. In this instance, the repository is ghcr.io, which is the repository for the linuxserver group's images.  This line tells docker to go to that address and pull the latest "papermerge" image.

Whew!  That's a lot, but it's all pretty simple and logical.  Now, imagine that you want to change the timezone (maybe you moved), or you want to change the restart variable to "always".  You would need to stop this particular image with the command docker stop papermerge and then re-enter the entire command above, with your changes, as a single command.  This could get tedious, especially if you have a lot of docker containers that might need to change at the same time.  This is where docker-compose comes in.

Docker-compose

Docker compose allows you to use YAML configuration files instead of commands.  For example, instead of the above docker command, a docker-compose.yml file for the papermerge image looks like this:

---
version: "2.1"
services:
  papermerge:
    image: ghcr.io/linuxserver/papermerge
    container_name: papermerge
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
      - REDIS_URL= #optional
    volumes:
      - </path/to/appdata/config>:/config
      - </path/to/appdata/data>:/data
    ports:
      - 8000:8000
    restart: unless-stopped

The beauty of this is that format is pretty much the same, but this is a text file that is easily editable.  When you want to bring the container up, you just run docker-compose up -d in the same directory as the docker-compose.yml file, and docker will create the container based on the parameters in the docker-compose.yml file.  If you need to bring the container  down because you made changes to the compose file, you'd just run docker-compose down.

The only thing tricky about YAML files is that the spacing has to be exactly correct, but that's not very difficult.  The only thing to keep in mind when using docker-compose.yml files is the version number.  This relates to the version number of docker-compose itself.  If the version of the docker-compose.yml file you're attempting to run is 3.7, but you've only got 3.2 installed, you'll need to update the version of docker-compose on your system before it'll work.

And that's the scoop on docker!