Transcript
  • Servers and Tools

The systemctl Command

From the class:  Managing Processes with systemd

If we take a look at the manual pages for system D, notice in the description it says that when system D first starts it runs as the first user space process. And it acts like an init system that brings up and maintains user space services. And that means that services or processes that are user programs like ones that we install, they're going to be managed by system D and they're going to be children of this root process with a process ID of 1.

We saw examples of that in the process class. But let's take a look at these processes now by using the ps command. So I'll say ps and then use the ajxf options. And I'm going to pipe that output into less so that we can page our way through it.

Now, take note of these first two columns. The first one is the parent process ID and the second one is the process ID. So this way, we can see the parent-child relationships between these processes.

If you scroll down a little bit past the operating system processes, you'll see this init process that the man page just talked about. See it here? It's s bin init. And its process ID is 1. So this is the first process that gets loaded, and this is run by system D.

All the other processes in the system that aren't already a child of another process will have a parent ID of 1. So they'll all be children processes of this init process. And if we scroll down a little bit, you'll see examples of that.

Notice how all the parent process IDs are 1. Now, we can get into nested levels of processes like we saw in the process class. This is an example of one. This is the SSHT. This is actually our current session right now because we logged in using SSH.

And notice that its parent process ID is 1, and then it has a bunch of children underneath it. The primary way we'll interact with system D is by using a command line tool called system controls, ctl for short. We can learn about the tool by using the help option and navigating through the different options and commands that are available to us.

I'm going to show you around the most common ones. But if you go all the way down to the bottom, you'll see that there's not only commands for managing services, but also for the overall system, like powering it off, rebooting it, halting it, et cetera. So I'll press Q to get out of this.

One of the things that you need to understand about system D is that it can manage all kinds of things. These objects that it manages are called units. Units could be services, which are like processes that run on the machine, or they can be other types. Let's take a look.

If I type system control, there's a command called list units. And that's going to just print out to the console all the different units that system D is aware of. In the left, notice that the top column here-- it's a little hard to read-- but the column name is unit. And then load says whether or not it's loaded or not. So does system D know about it.

And then we can take a look at its state. It could be active and running or it could be failed Or. It could be exited or any one of those states. And then a brief description of what the unit actually does. And notice that the unit names have these extensions. So for example, .device is a device unit.

And if we scroll down a little bit-- let's see here-- here's another type of unit. A mount. So this would be if we were mounting a file share. We can have system D manage that for us as well.

And then there's a service unit. Service units are the ones that we're going to spend the most time on in this class. And a service unit is a process that we want system D to manage. So it's usually associated with applications that we install, like Nginx or Mongo or even our own custom application process. So these are called service units.

Another type of unit we're going to talk about is called a target. So let me scroll down and see if we can find one example of a target. You can see sockets and a couple of other ones that are here.

Targets are not actually something that's going to be managed by system D, but more like a label or something that we can identify as a dependency. So for example, if we wanted to start up a unit automatically, one of our services, when the graphical user interface becomes available, we could say we want to depend on the graphical.target unit.

Or if we wanted to wait for networking to come online, we could depend on the network target unit. So you'll see examples of these when we start configuring our services.

We can provide an option to list units, which is type. And that will filter the list by just the type of unit we want to look at. For example, if you wanted to see those target units, we could just say type equals target, press Enter. And now all we see are the target units. And this will be a little bit more easily digestible.

Let's get our hands dirty here and actually play around with a real application that uses system D. So I'll press Q to exit out of this screen. And let's install the Nginx web server. And so to do that I'll say pseudo app get install. I'm going to use the apps package management system that comes with Ubuntu, and I'm going to install Nginx.

Nginx, again, is a really popular web server. Evented Mind uses it and a bunch of other websites use it as well. And once it's done installing, it's automatically going to provide the configuration files that system D needs in order to work with it.

Now I'll use the list units command again and we'll filter it by type equals service, because that's what Nginx is. It's a service. And if you scroll down a little bit, you should see it in the list. So notice Nginx here appears in the list and it's loaded automatically for us just by installing it. And it's active and it's actually running.

And you get a little description here that says it's a high performance web server and a reverse proxy server. We'll cover Nginx in more detail in another class. Let's actually confirm that it's working in the browser.

The virtual machine we configured with Vagrant using the Vagrant file that's in the root of our project folder is set up to map this IP address to our virtual machine. So if you open up a browser and navigate to 1921683310, that will take you to port 80 of our virtual machine.

And notice Nginx is running and we get this website for free that just says welcome to Nginx. And we get all that just by installing Nginx. So this shows us that the Nginx process is indeed running.

We can find out the status of a particular unit by using the system control status command and then passing the name of the unit. So in this case, we want to know the status of Nginx and it's a service. So we say Nginx.service.

Now, the service part on the end of this is assumed. So if we leave this off here, system control will just sort of add it automatically. So this is the default.

So we can just say system control status Nginx and we'll get back this nice console view that says that system D knows about the Nginx service and it's loaded and it's also active. That means the process is actually alive and running. And we even get a process ID which is 2012 and then the C group that it's a part of.

If we look at the process in the process tree by using ps, we'll actually see it. So you see it there at the bottom, Nginx. And it has a master process which has the 2012 ID. And notice that its parent is 1, so that's going to be the init process. And it has this one child process which actually responds to the web requests. And its parent is this one up here.

So we've got two of these processes that are being managed by system D. In order for a unit to work with system D, we have to enable it. So just installing it is not enough. We have to enable the service. Now, that happened for us automatically when we installed Nginx.

But just to check, we could say system control is enabled. And then give the name of the service. And it says that it is enabled.

Let's say that, just to show it, we want to disable it. Well, we could say system controlled disable Nginx. And oh, I need to do that with pseudo privileges. So we'll say pseudo system control disable Nginx.

And now it's disabled. And that means that when we reboot the system, Nginx will not automatically be restarted. So it's available to system D. We can enable it again. But we've disabled it which means it will no longer partake in the automatic restarting.

Let's go ahead and re-enable it. So I'll say system control enable Nginx. And we can check its status again to make sure that everything worked OK. And everything looks good.

Now, let's stop the Nginx process. To do that, we can just use the stop command like so. I'm going to have to do this with pseudo privileges as well. And now Nginx is stopped.

And if we take a look at the status now, it's loaded. So system D knows about it. But it's inactive or dead. It means that there's no process associated with it.

To restart it, we can just use the start command. So pseudo system control start Nginx. and now it's started again with a different process ID because it's a new process this time.

Two other commands you'll use often, especially if you're deploying to your own servers, is restart and reload. So let's say we want to restart the process all in one swoop without stopping and starting. We can say system control restart Nginx and that will restart the process. Oops, again, you need to do it with pseudo.

So pseudo system control restart Nginx. And the last one is reload. Reload will keep the same process, but let's say that Nginx loads up a configuration file and we change a couple of those settings. We can tell it to just reload that configuration file without restarting the process or shutting down the process.

And that means that if people are trying to hit our web server, they'll still be able to do that. But Nginx will load up the new configuration file. So reload is a really useful command.

One of the nice things about system D is it provides a uniform interface for working with services across the system. We just used Nginx as an example, but let's install another program that you might use.

If you're playing around with Meteor, you'll be using Mongo as the database. So we can say pseudo app get install MongoDB. And that'll install Mongo onto the system. It might take a couple of minutes to finish this installation process because Mongo is pretty big.

Once it's done, we can use system control just like before. And we'll start off by querying the status of the MongoDB service. And here, we have it. We have an active running process and it has a PID of 7067.

If we wanted to stop MongoDB, we could say system control stop. And oops, I always forget to use pseudo. So just in case you forget, ' can say pseudo, bang, bang.

And now it stopped MongoDB. And again, we can start it like this. So this is how we're going to be working with all the services on Ubuntu. And as we get further and further along and into deploying our own servers, we can use system D to uniformly manage all of these services.