From the course: Ubuntu Linux: Essential Commands and System Administration

Booting and systemd targets

From the course: Ubuntu Linux: Essential Commands and System Administration

Start my 1-month free trial Buy for my team

Booting and systemd targets

“

When a system goes from powered off to up and running, it goes through a boot process to bring up the system to a usable state. This process, as we'll see in another video in this course, has some technical details that make it work. It's not just about applying power to the components and having them suddenly work. In that vein, we also can't just remove power from the system when we're done with it. So in this video, we'll take a look at rebooting and powering down a machine safely. Modern computers are complex, so we can't just necessarily treat them like appliances. When we go to shut off a light, we can flick a switch, and that's that. But a computer has a lot more going on, and simply removing power from it can cause all kinds of problems. If there was information waiting in cache to be written to the disk, it could be lost. If another user is currently using the system, their work would be interrupted or lost. So we have a procedure that shuts down a computer in an orderly way to try to avoid these problems. If we want to tell a system to power down and remain off, we shut it down. If we instruct the system to shut down and then immediately come back online, we tell it to reboot. Both of these operations, though, involve the system going through the shutdown process. That process notifies other users of the system that the system is going down, and whoever initiates the shutdown can optionally set a period of time before it happens and send a message to other logged-in users. Users with the appropriate access level can cancel the shutdown too, if need be. When the shutdown process takes place, the system notifies processes that are running, telling them that they need to do whatever they're designed to do in the case of a shutdown, including saving data, writing log entries, or anything else needed to correctly end what they're doing to minimize data loss and to end up in an expected exit state. Data in caches, operations in queues, and information in memory need to be dealt with in a way that's appropriate for each of them. At the command line, we can reboot or shut down the system with a shutdown command, which can take a few options. Normally, we'd write shutdown -r now or shutdown-h now to either restart or power off the system immediately. The now parameter tells the system to go down now, though we could add a time with either a plus and some number of minutes or with 24-hour format time if we want the system to go down at a specific time rather than in a specified amount of time. For example, I could write shutdown -h +5 to tell the system to shut off in five minutes. If I wanted to, I could cancel that shutdown with shutdown -c. And then after the five-minute period from the previous command elapsed, the system wouldn't shut down after all. I mentioned before that we can say "now" instead of a specific time. So let's use that and restart the system. I'll write sudo shutdown -r now. The machine notifies users that it's going down and then immediately informs processes that it's going down. The operating system kicks off its shutdown sequence and the machine restarts. I'll log back in here and go back to my terminal. There are a few other options in the manual pages, too, if you'd like to explore them. During the boot process, a lot of things happen, and the system is brought up through various states of operation, each one more complex and functional than the last. And we can tell the system which state to move to as well. Historically, Linux had run levels, which were discrete operating modes such as single-user mode, multi-user mode, a graphics mode, reboot, and so on. Each of these run levels, which were labeled 0 through 6, involved startup scripts for various services, usually written in shell script, and they could be fairly delicate to work with. With systemd on Ubuntu, instead of run levels, we have targets. These can start various other targets and services, and we can find the targets and files in the /lib/systemd/ system folder. We can use the systemctl get-default command to see which target is the default for the system. And here, we can see that we're at graphical. An Ubuntu Desktop System generally runs at the graphical target level, which requires the multi-user target, which itself requires various targets, each of which has other dependencies and which start up particular services. We can take a look at the targets that are currently active to get an idea of how many different targets make up the current state. I'll press Q. Using systemctl isolate, we can isolate a particular target or service to start whatever it needs and stop everything else. We can do this to switch into a rescue mode, for example, or to switch up to a multi-user mode if you've been in single-user mode. The services that various targets start are defined by service files that systemd keeps track of. Let's take a look at the Rsyslog Server Service with less /lib/systemd/system/rsyslog.service. Browsing these files can give us an idea of what they look like. The unit information shows the name or description of the service and Requires shows what needs to run or be present before this service can start. In the Service section, we have information about what command is run when the service has started, how to handle shutdown, and whether to reload on failure. Rather than writing a shell script to check things and conditionally run a command, this unit file syntax keeps things standard and human-readable. And down here at the bottom, we can see that this service is wanted by the multi-user target. A target will try to start everything that it wants, and everything that's wanted by a particular service is linked into a related folder. I'll press Q, and let's take a look at ls /etc/systemd/system/multiuser.target. wants/ to see what this target wants. That's a lot of services. Usually, when software is installed, if it needs a service file, the installer will take care of creating it and making systemd aware of it. We can also write our own service files in the /etc/systemd/system/ or /etc/systemd/user/ directory to tell systemd how to start a program, what it requires, and which target to associate it with. When you enable the service, systemd will symlink your service into the Wants folder for the target specified in WantedBy. Once the service or target is available, we can manage it with the systemctl command using the enable, disable, start, and stop commands. And we can find out more about it with the status command. We'll explore that a little bit later.

Contents