Systemd Deep-Dive: A Complete, Easy to Understand Guide for Everyone

[Music] thank you greetings Linux fans in this video we're going to go over systemd now calm down it's okay um system deep isn't all that bad there's some unfair stigma against it within the Linux Community but you know putting that toxicity aside and being unbiased it really is a good solution there's a lot of features that you should be aware of and by learning systemd you'll know how to manage resources on a variety of Linux distributions because it's well the most common init system when it comes to Linux nowadays now if you don't already know what an init system is the init system of your Linux installation is the most important process it's the very first process that starts on your system and its job is to schedule all other processes on that system so as you can imagine systemd has a very critical part in any server or Linux installation that it's a part of and in this video I'm going to teach you everything that you need to know to be up and running with systemd the way that this particular video will be structured is that I'll start out with some general information and beginner focused examples when it comes to system D examples such as starting and stopping services from there we'll move on to intermediate and then later more advanced topics now the thing is systemd is a very large topic so it's impossible for me to cover everything in one video without it being something ridiculous like five hours long now sure the runtime of this video is going to be larger than most but what I wanted to do is focus on the most common use cases of systemd the things that most Linux administrators will need to know how to do and you'll know how to do those things by the end of this video what I'll start with is some basic examples of starting stopping and restarting Services you know the bare minimum things that you'll need to know when it comes to system deep and then from there we're going to look at more complex topics as the video goes on anyway with all of that out of the way let's just Dive Right In and check out systemd thank you so in this section we'll go over some basic information around systemds so you can better understand what its purpose is and how it helps us in this section after this one we'll start with some Hands-On activities so you can start learning it but let's get some basic information out of the way first so going all the way back to the beginning what exactly is systemd well I mentioned earlier that system D is an init system so let's make sure that we fully understand what that is first the init system of a Linux distribution is a type of process a process is any task that runs in the background something you don't regularly see but does its work quietly behind the scenes but an init system isn't just any process on your Linux system it's the most important process of all in fact it's so important that the init system is always the very first process that runs when you start up your Linux instance for this reason init systems are also referred to as pid1 short for process ID number one and that's the case because the init system literally always has process ID 1 since it's the first to start the reason why your distributions init system is so important is because its job is to manage all other processes when you start a process on a Linux server such as Apache or nginx in the case of a web server the request to start that process is sent to the init system which then starts it up when you stop a process reload a process restart a process or so on the init system is what does all of that for you and to see what I'm talking about let's open up h-top in h-top if you haven't seen it before is a Linux program that you can use to get a look at what's going on behind the scenes as something that I've covered in its own video and I'll leave a card for that video right about here anyway h-top is what you're seeing on the screen right now and as you can see we have a list of processes we can see that on the right hand side and if I click right here to sort by the PID notice that systemd is literally pid1 just like I was saying earlier system D itself is a newer init system debuting back in 2010. it differentiates itself from its ancestors in that it has a much more modern approach to process management and these features give systemd the ability to enable the administrator to schedule tasks to only run when specific criteria is met and also to ensure a process is always running it allows you to configure logging oh DNS is resolved and much more so yeah there's a lot to it but don't let that scare you we're going to make this look very easy let's get started with some Hands-On examples and you'll be familiar with systemd in no time so let's get started the first example is that we'll take a look at are very basic and beginner level but are also extremely important to know in particular the first examples will show you how to work with systemd units units in systemd refer to anything that is able to manage for you units include but aren't limited to Services timers mounts Auto mounts and so on to keep it simple in this entire first section we're going to focus primarily on services and the reason why I'm mentioning this right now is because this is something that I recommend you commit to memory in order to save confusion later so in summary units are things that systemd can manage for you and a service is a type of unit and I'm going to repeat that units are things that systemd can manage for you and a service is a type of unit and again we'll be working only with services in this section but I just wanted to make sure that you know this because this is something that confuses newcomers you'll hear of terms such as units and services and you might not know the difference well unit again is something that systemd can manage for you and a service is just one of those types of units and managing Services is just one of the things that systemd does for us so let's start working with Services right now we can use any package that contains a service file as an example but to save time let's install Apache and how you go about doing that depends on the distribution that you're running if you're running Debian Ubuntu or anything based on one of those distributions then what you'll do is run sudo apt install and then Apache 2. what that'll do for us is install Apache Apache again is a popular web server service and by having this installed your server becomes a web server it's serving a web page now if you're running something like Fedora sentos red hat or a flavor of Enterprise Linux then what you'll do is change app to dnf and then in that case you'll change the name of the package to httpd because the package name is different on other distributions so we're going to run one of those commands to get Apache installed and then once you have it installed we can continue now for those of you that are running a distribution of Linux other than one of the ones that I've mentioned then you are probably an intermediate or Advanced Linux user and you're only watching this video to prepare constructive criticism if that's you how am I doing so far in my case the dnf command is what I'm going to run because this particular computer is currently running Fedora so I'll press enter and actually I already installed Apache before I hit the record button I forgot to remove it but you get the idea I have Apache installed right here in my footage PC and what that means is that I should be able to access it if I switch over to a browser what I could do is just navigate to localhost right here in the address bar and what that's going to enable me to do is view the sample Apache web page which doesn't work for some reason and why is that well that brings us to our very first systemctl command which is how we interact with systemd for the most part so what we're going to do is check the status of Apache now on your end it might have already been running especially if you use Debian or Ubuntu if that's you then the previous step probably worked but distributions based on Enterprise Linux and that includes Fedora sentos and a number of others and the process won't be started automatically when you install Apache to find out what we could do is run systemctl and that's the command that we're going to use primarily when it comes to using systemd we want to check the status of something and what we want to check the status of is either going to be httpd and that's going to be the case if your package manager is dnf otherwise if you are using a Debian or Ubuntu based distro then the service is going to be called Apache 2. it doesn't matter what yours is called you just have to know in my case I installed httpd so the service name will be the same as the package name anyway I'll press enter and there you go we've just checked the status of a unit with systemd the system CTL command or system control command is what we use to inspect running services in this case I just ran status against it because I wanted to find out is it running and as we can see here it's not running in fact you can see that it's inactive that's what it shows right there we also see that it's currently disabled now when a service is disabled that means it's not going to start up when the server starts up you have to start the service manually we can always enable it if we want to go ahead and do that but what we're going to do right now is well start Apache so we'll use sudo systemctl and then start and then the name of the service in my case httpd just like that so now let's check the status again and we can see that it's running so now we've seen two variations of systemctl already so what I'll do is press Q to break out of the status window here and return to the command line so far what you've seen is systemctl and then status then we'll type the service name right after that to check the status of that service and you also saw an example of me starting a service in this case it was httpd but it really doesn't matter what the name of the service is because you're going to go about this the same way regardless so you now know how to check the status of a service and you also know how to start a service and considering that I started the service if I go back to my browser and what I'll do is refresh the page and actually it's not going to work because I have https and a name here so I need to just drop that out of here this is not a secure site at least not yet but anyway we see the Fedora test page here and this is going to look different for you depending on what your distribution is but as you just saw after I installed Apache I was able to start it up and now it's running now what I'm going to do is show you an example of stopping a service with systemd so again I'll type sudo and then systemctl I want to stop a service and I'll stop the Apache service now if I go back to my browser and then I attempt to refresh the page Watch What Happens the test page is no longer available and that makes sense we need a web server to serve a web page and the web server that I installed is Apache and I stopped the service so now there's nothing on the server to serve this webpage so I'm unable to connect so of course I can go ahead and start it and as soon as I do that it's available again now in addition to stopping starting and checking the status of a service you could also restart a service as well this is useful if you've changed a configuration file and perhaps the application needs to be restarted for the changes to take effect pretty self-explanatory but what it's going to do is stop the service and then start it up again in my case there's going to be no difference here the restart process happens very quickly so as you can see the test page still works and believe it or not that's the majority of the commands that you'll need to know when it comes to systemd systemd runs in the background and is completely self-sufficient it manages things for you the only time you'll interact with it is anytime you want to check the status of something or alter the status of something so those are four of the six most important commands that you'll need to know but what are the other two well let's take a look at that right now back in the terminal let's see how we can take care of the fact that Apache isn't going to start up when this particular computer starts up again here's the status page you can see that Apache is disabled it's currently running which is great but it's well disabled so if I restart the computer then Apache will not be running now correcting this situation is really easy to do back on the command line what I could do is run sudo and then systemctl enable and then the name of the service so again httpd in my case it might be Apache 2 for you but you get the idea and now it's telling me that it created a Sim link which is what happens when you enable a service and if I check the status again we can see that it's not only running but it's also enabled now the preset of disabled means that the distribution has configured system D such that well new services will be disabled by default it doesn't really mean a whole lot though you can always enable the service if you want to start it automatically but in the case of well Debian and Ubuntu it's typical that they'll enable the service for you the idea being you wouldn't have installed it unless it's something that you wanted to use whereas when it comes to Red Hat based distributions you know Fedora sent to us and the others they're not going to make any assumptions at all they're going to disable a newly started service a service comes from the package itself so here it's going to be disabled but we can always enable it if that's what we want to do now before we move on one thing that I do want to point out is if I scroll through the output right here we have some log entries down here at the bottom you're not always going to see that when you check the status of something but if you have permission to see the information it's going to be shown right here again you're not always going to see that but if you're having problems it might be useful to see this because you might see the error message right here in the output anyway I'll use Q to quit out of here and let's continue at this point what we're going to do is take a look at how to disable something you could probably already guess the Syntax for that be used sudo systemctl enable and then the name of the process to enable it but if we wanted to make sure that it does not start when the system starts we can disable the service so if I check the status again as you can see it's now disabled so at this point you've learned the six most important commands when it comes to systemctl or system D in general system CTL start stop restart status and also enable or disable and this will be the majority of your use of systemd sure every now and then you'll have to go deeper than this but these are the commands that you should know at an absolute minimum now I hope you'll continue on because everything in this video was curated as things that you should probably know for your career but these six commands are the bare minimum that you should know when it comes to systemd now from here what we're going to do is dive in even deeper and take a look at how systemd is structured how it's laid out or specifically we're going to look at directories where the unit files are stored in the first place so earlier I mentioned that systemd uses unit files a unit file pertains to anything that it can manage and when I say file I mean file system D is looking at files or unit files to understand how it needs to interact with processes but where exactly are these unit files stored well let's take a look at that and on the screen right now is an example of a service file don't worry so much about the contents right now we'll get to that later but anyway service files are just text files that contain instructions that tell systemd how it needs to manage that particular service so what I've done here is I've pulled up the service file for Apache now service files can be found in any of several directories and these will have a file extension of dot service at the top of the window right now we can see the full path and the name of the file for this particular service right here so if you wanted to take a look at the contents on your end you could do that now on Debian or Ubuntu it's going to be apache2. service but you get the idea anyway let's go ahead and close out of here and take a look at the directories that are most common for service files in fact there's going to be three different directories that we'll be paying attention to and the first one will be slash Etsy slash systemd system this is going to be the most common directory that you'll find in the majority of how to's that you'll see out there that go over service files now we'll look inside these directories shortly but let's go through the three most important ones right now so that way you'll know which ones we're going to focus on the second one is going to be slash run system D and then system and the third one is going to be slash live slash systemd system now again each of the directories that I just gave you are going to have systemd unit files saved inside them anyway let's go ahead and take a look at the contents of one of those directories and randomly what I'll do is choose the slash live system d slash system directory and take a look at this we have a number of service files here but we actually have more than just service files we have a mount file we have a Target file we have a service right here as you can see we have a socket file there's a number of different types of units here or unit files that are inside this directory and this might make the relationship a bit more clear I mentioned that we're going to be focusing on service files but that service files weren't the only kind of unit file again a service is a type of unit so a timer is a unit and then scrolling up of course we have a socket unit we have a Target and so on but anyway I just wanted to mention that so the relationship will be more clear service files are going to be the majority of what you'll work with but just keep in mind that there's different types of unit files but why is it that we have several different directories where these unit files might be stored in well each one of these has a very specific purpose now the one that I just showed you was Slash live systemd system now if I take a look at that again and then I'll scroll up what you'll notice we have httpd.service right here when we installed Apache that particular service file was installed for us so typically you don't have to create your own service files although you can most of the time the service file will be provided by the application that you install so generally speaking there won't be too many situations in which you'll need to customize this but we will see that process but anyway we can see the httpd.service file that came with Apache right here so when I had the service file on the screen that's the one that I had on the screen so what we can glean from that is the slash live systemd system directory is the directory that installed service files will go into so when you install a package and it includes a service file it's going to be found inside that directory now similarly we also have slash run slash systemd system which is going to store runtime system to units I don't have any on my system right now this directory in particular is going to be the one you'll look at the least now another directory that I mentioned was the Etsy systemd system directory and I also mentioned that this is going to be the most common one that you'll work with what I'll do on the screen is show you the three directories ordered from the highest priority down to the lowest so as you can see the lowest priority is slash live systemd system any service file or configuration that's stored in a directory of a higher priority is going to well take priority that means that any service files or configurations that you might have in slash run slash systemd system those are going to take priority over slash live systemd system the biggest priority of all is slash Etsy systemd system no matter what anything you put inside that directory will have the ultimate priority it's the directory that system D favors more than any other so if you want to make sure that your configuration takes effect you'll want to make sure that you add the changes to the directory with a higher priority so the way this works is when you first start up your Linux system it'll start system D and system D will go into these directories looking for unit files if it finds any and it will it's going to load those into memory now due to this priority if you were to ever create your very own service files manually you'll definitely want to save them in SC systemd System since it has the higher priority again you can make sure that the service file is taken into account in fact you can create an override file which we'll see later in this video that will allow you to override configuration that's found in a lower priority directory that also saves you from having to type everything manually now again slash live systemd system is a directory with the lowest priority but it's also the directory where installed Services go now the reason why the package manager is going to install service files into the lowest priority directories because you have an opportunity to override the settings again we'll see that later when you install a package that contains a unit file you'll find the unit file in that directory although you can create your own unit files and store them in that directory as well it's recommended not to do that and to use slash Etsy systemd system not just because that directory has a higher priority although that is part of the reason the thing is unit files that are stored in slash live systemd system might be overwritten if a package is updated now the slash run slash systemd system directory contains what are known as runtime units something we won't be looking at during this video in particular but I mentioned it just so you can be aware of the fact that it exists anyway now that we know which directories contain unit files for systemd and we also know the priority order let's take a closer look at an actual system to unit file all right so in this section we're going to take a look at a systemd unit file specifically a service so that way we can better understand how they're set up there's going to be many different examples of different fields and configurations so there's no way that I can cover every possibility that you might find in one of these files but what I'll do is cover an example right now that will give you a general idea earlier we installed Apache so let's take a look at that right now so what I'll do is just use Nano and then I'll edit slash live system d slash system and inside there since I've installed Apache here on this particular system it's going to be called httpd.service just like that again the name will be different on other distributions you get the idea and here we have the service file now we can ignore the error down there that's telling us that this particular service file is unwritable that just means that I didn't use sudo which was intentional I really don't want to modify this particular file at this time but I did want to bring this up in an editor so we can go through some of the commonalities that you'll find here when it comes to system D unit files oh sorry I was just Consulting my own book actually you know that's something that I do from time to time because unlike what many of you might think I don't memorize everything that I teach you guys sometimes I actually look at my own book if I want to remember how to do something that I don't do every day but since I'm on the subject of this book check it out mastering Ubuntu Server 4th edition written by Yours Truly it's available right now and I think you're going to love it so if you're looking for an Ubuntu book to teach you everything that you need to know when it comes to managing real Ubuntu servers check it out so definitely check out the book I would really appreciate it anyway let's get back to the video now for the most part we have three primary sections here we have a section down here called install which goes off the edge of the screen but anyway we see unit service and install and each of these sections is designated by brackets and the name of each section will have its first letter capitalized and it's important that you don't change the syntax as the file is well case sensitive unit with a lowercase U for example doesn't factor in again system D is expecting the first letter to be capital and you put the different sections in Brackets like you see right here underneath each section we have configuration for that section some of these fields aren't required While others are optional but first let's understand the purpose of each of these three sections before we look at what's underneath the unit section contains more general information about the unit for example a description which describes what the unit is for the description here is just identifying that the unit file pertains to Apache which is a web or HTTP server next in this example we have wants that may not show up for you Debian or Ubuntu users because again not every field is required anyway wants identifies a sort of prerequisite unit that must be started first in this case we have httpd init.service and that's not going to be found on the Debian version again there's differences from one distribution to another but let's not focus so much on the differences themselves let's focus on the unit file now what wants does is outline that something else is required and it must happen before this unit file can start up it's quite common that you might have something like network.target and we see that here underneath after but that could be under wants as well that's a prerequisite and network.target means that we want to wait until the network is available before the process starts I mean it wouldn't make sense to start up Apache before the network nobody can access it anyway we may as well start it up after the network comes online so that way people can access it as soon as the network is available now we also have before as well as after here we have afternetwork.target we have some other unit files there as well and these are similar to wands but focus on a specific order when it comes to before and after you can have multiple units separated by spaces which is exactly what we have here so that way if you have more than one requirement you can not only specify that but also specify in which order things start up if that matters in addition we also have a documentation field in this field you can configure what it lists as the documentation source for the unit and this one right here is referring you to the man page now you might see something like a URL here on your end if you're using a different distribution but regardless whoever packaged this particular service file has decided that the documentation should be set to the man page which is what you see right here under the service section we have configuration options that are specific to service files and these options configure how the unit is treated when it starts up and the first option underneath this section is the type when it comes to sentos the type is set to notify now this option is almost exactly identical to another type known as simple the simple service type is the default and as such it's quite common the simple type causes system D to consider the service to be started up as soon as you start it in contrast notify is the same except it's not configured to be running until the process tells systemd that it's ready whereas with the simple type it's not going to take that into account if you start it it's going to go ahead and assume that it's running now in the Debian and Ubuntu side you probably have this set to forking this means that the process is considered to be started when other processes are spawned from a parent process and then that parent process stops to where the children are the only processes that are running that's why we have a different type on two different distributions for the same application comes down to design Decisions by the team that maintains the distribution and it's best that we don't change this unless we have a very specific reason to do so now other things we have here is exec start and also exact reload we go ahead and scroll down here and Center that for us we could also have exact stop as well and the meaning is going to be similar between the three for example exec start is what happens when the process is started up that's the application that's going to be started along with the service so in this case slash user slash S bin slash httpd is going to be the process that starts up when we start the service file when it comes to exec stop that's the opposite when the service stops it's going to execute that command and we don't have that here in the case of Centos so it doesn't even have exact stop again some of these fields are optional you're only going to include the ones that matter for your use case but what exactly is up with reload I mean we've started a service file we've stopped a service file we've checked the status of it we've restarted it but what's reload and how does that differ from restart well similar to how we restarted a service and as a refresher it would look something like this sudo system CTL restart and then the process name but instead of restart we could type reload now reload is similar to restart but it's not a full restart of the service reload will cause the process to reload its configuration files which enables a setting to take effect without users getting disconnected in the case of a web server like Apache this is preferred since we'd rather not disconnect users from our website if we don't have to now not every configuration change supports reload over restart and not every service file will contain this it's something that the developer of the service will add if there's a functional reason for this to exist of course there's additional values that could be here as well but I'm going to skip those as the deeper we get into systemd at this point the more we're getting into distribution design choices that go beyond the scope of this video anyway continuing let's look at the install section and this section isn't required but if it is present it will configure what happens when a unit file is enabled or disabled and as we went over earlier a unit that's enabled will start up when the server starts up and disabled is the exact opposite of that but when a service is enabled we can use this section right here to set up how that's handled when it comes to wanted by which is what you see right here that has to do with dependency relationships similar to after and before which is what we found in the unit section above and what that means goes beyond the scope of this video but I will give you a summary with Linux systems we have different run levels that define various operating stages multi-user.target defines that the system must have reached a state where multiple users can use the system at the same time so in this case Apache will not start until that stage has been reached now what I just went over is a very basic overview of systemd service files and I'd love to go over every possible detail that might be within these files but in that case the video would be over an hour or two longer than it is right now but with what I've gone over that should give you a basic idea of how these files are structured and then depending on the scope of your project you'll add configuration items as necessary but what do you do if you want to alter one of these service files well that's exactly what we're going to explore next all right so at this point as we continue along our journey we're going to start looking into customizing unit files in most cases unit files that your distribution provides are typically adequate but as you advance your Linux skills you'll likely run into situations where you'll need to either edit an existing unit file or maybe even create your own so first let's take a look at editing or overwriting an existing service file and you know what there's a dedicated command that you could use within systemd for this purpose that command is systemctl and then edit so to edit a service file you can run systemctl edit like you see here and then you give it the name of a service file I'm going to type httpd.service I don't have to type the path to it because systemd knows where to find its own service file so I only need to give it the name so I'll press enter and let's see what happens and actually I'm going to need sudo here I almost forgot see even I forget to do that sometimes anyway what we have right here is a service file or well what is this exactly but what we have right here is a very special override.conf file a config file that's being created as a part of the systemd edit command as you can see at the top the path is going to be slash Etsy slash systemd system slash httpd.service.d and then it's going to create an override file underneath that directory but why exactly is it going to create an override file in that directory instead of the directory where that unit file actually resides in well the reason why has to do with priority like I mentioned earlier the Etsy systemd system directory has the highest priority so when you use systemctl edit that's where it's going to save the file again anything in that file takes priority now what we have here is the original unit file but everything is common without and this is here for your reference I mean you might be tempted if you wanted to make a change and the change we're going to make in this video is spoiler alert is going to be here in the unit section and we're going to edit the description that's a fairly inconsequential change very easy to make I just add something here so what should happen is when we save the file then the changes right here in this editor will be merged with the existing file that's not going to happen though and I'll show you why so anyway Ctrl o and then enter to save it they said it wrote 57 lines keep that in mind anyway Alex it out and let's take a look at it now the original file is going to be unchanged you see right here description and it's the original description but it saved the changes or at least it said it saved the changes in the Etsy system D system directory let's take a look at it now unless I'm blind I'm not seeing anything regarding httpd inside this directory and here's why let's run that previous command again to edit the service file so again that sudo system CTL edit and then the name of the service file but anyway why did our changes not get saved well this is a situation that a lot of people run into even I've run into this myself the first time that I've done this you might think that going down here and on commenting something that you want to change for example in the units section we might want to change the documentation or the description but that's not how you do it for some reason it's easy to miss but it tells you right here that edits below this comment will be discarded so that means any changes you make down here will not be saved they will not be taken into account so following the instructions here any changes we want to make should be made here underneath the second line and above that notice line that tells you that anything below it won't be saved so if we want to alter something in the unit section you need to type the name of the section right here in the proper format that contains the feature that we want to change and what I'll do is scroll down let's see what we can change I think description is probably easy enough so what I'll do is just type description right here I'll set it equal to Apache is awesome let's save the file and close out now it says that it installed it and it tells us that it did so in that directory right there so let's just take a look at it so we have a directory that has the same name as the service with a file extension of Dot service.d and then underneath that directory we should have an override.config file and we do it contains only the changes that we've made with the systemctl edit command it doesn't contain the entirety of the systemd unit file it only contains what's changed because again anything in Etsy systemd system is going to take priority so any conflicting settings that you might have here are going to take priorities so we already have the unit section in that unit file and then within that we have a description but here in the override file we're setting that to be equal to something else if we wanted to undo the change we could simply remove the override file which is what I'll do right now and what I'll do as well is show you another method of editing service files just like before we're going to use systems ETL and we'll use edit but what I want to do is use the option Dash Dash full I'll give it the same service name and let's see how this differs and check this out if I scroll down we have the entire service file here so the difference is when we run systemctl edit we're going to create an override file that gives us the option to add only the sections or settings that we want to override and have it stored in an override file rather than having the entirety of the systemd unit all over again but when we use the dash dash full option what that's telling systemd is is that we want to start with an entire config file an entire service file and use that as the base now notice that I haven't made any changes here I'm just going to save the file and then I'll exit out so we've ran that command we didn't make any changes so what exactly happened well if I list this storage of Slash Etsy systemd system you can see that we have an httpd.service file right there so now at this point we have one here in Etsy systemd system and we also have the original at slash live systemd system but what's the difference between these two files there shouldn't be anything different because I didn't make any changes but let's verify that I'll use the dip command and the first file is slash Etsy systemd system and then the file name of course is httpd.service and the original is located at slash live system d slash system with the same name let's see what's different nothing if there was a difference between the two files we would see output here with the div command but since there wasn't any output that means these files are identical so what you can glean from this is that when you run the systemctl edit Dash Dash full command against a service file that's going to make a copy of the entire service file and save it in Etsy systemd system so any changes that I make to that file are going to take priority and the other benefit is the service file underneath slash live systemd system might be overwritten at some point if the package gets updated but the files underneath the Etsy systemd system directory will not be altered that way I don't have to worry about the package manager making changes or overwriting my customizations anything in Etsy systemd system is going to be retained regardless of the package manager so it's a safer directory in which to make your changes now there's another command that I need to make sure that you guys are aware of and I'll go ahead and type it out right now it's going to be sudo systemctl and then Daemon reload just like that but what does that command actually do well in this section we are making changes to systemd unit files the First Command created an override file and the second command created a copy of the original unit file this Command right here will reload systemd to make sure that it takes into account all the changes that we've made if we don't do this it's possible that the changes just won't take effect but with this Command right here we're basically telling systemd to take a look at its directories have a look for anything that's changed or is unique in any kind of way and just load everything into memory so that way everything we change regardless of which unit files we change will all be taken into account that's what this command does right here so anytime you do make changes to a service file or basically any unit file you'll want to make sure to run this Command right here but what about creating unit files from scratch how do you go about doing that well the thing is it varies depending on the application every application will need custom parameters so there's no way I can give you a template that'll go over everything but there are some well things that you could do to make the process a lot easier so what I'll do is switch over to a browser and I'll give you an example so right here we have our Fedora test page what I'll do is just navigate to a completely different website and I'll make the text a little larger so that way you can see everything right here anyway this URL just takes you to a file that's stored on a GitHub repository this one in particular is where the application known as sync thing and I wanted to give you guys this particular unit file right here as an example of a real world scenario where you might need to create your own service file in this case this particular service file pertains to sync thing sync thing is an awesome application that allows you to sync data between Linux installations so if you wanted to save a file and then have that file be accessible from all of your servers then sync thing is a way you could do that now this tutorial isn't about sync thing I'm just using this as an example but sync thing is something that you can install via your distributions package manager if you do that you'll get a service file automatically you don't have to create one but what if you wanted to use a version of sync thing that's newer than what your distribution provides in that case you might have to manually install it if you manually install it then how are you going to know what to add to a service file well in this case we have a service file that's provided to us from the developer so we don't have to guess or look into this right here we have a working example and this is a common use case when it comes to systemd if you're installing something manually chances are the developer has prepared a sample unit file like the one right here so what you'll do is just grab the example and use it as a starting point of course you'll want to customize this to make sure that everything matches so if your path to sync thing is not slash user slash bin sync thing then you'll want to change that so if you've installed that somewhere else then you'll just adjust that line but otherwise anything that is fine to be the default you can just leave alone and then what you'll do is save this file into the Etsy systemd system directory and then run your Daemon reload command to make sure this systemd is aware of this new file from that point on you can enable restart stop or do whatever you want when it comes to this particular service and that'll make sure that you're able to work with that application similar to any other applications that you might have installed okay so I'm going to stop the tutorial right about here this is one of my longer tutorials and I can always create a follow-up because there's more things that you could probably know about systemd that will be worthwhile in this video we went over the foundational Concepts the things that I think everyone should know about systemd so that was our Focus this time around but if you guys want additional content around systemd then make sure you click that like button and well I might consider doing a follow-up at some point in the future now other examples of systemd that we can go over in a future video include but aren't limited to systemd mounts Auto mounts timers and so on mounts are a way of making sure that something is mounted similar to the Etsy FS tab file and when it comes to timers those can actually replace cron believe it or not not that there's anything wrong with KRON but there's additional features with systemd timers that you can benefit from and those are all some of the topics that we might go over in a relay did video in the future anyway I hope this video has helped you guys out and I'll see you in another video sometime soon I'm working on a ton of Linux content for you guys that I can't wait for you to see so be sure to subscribe to learn Linux TV for the latest at Linux and I'll see you in the next video foreign [Music] [Music] foreign [Music]

Channel: Learn Linux TV

Views: 56,439

Keywords: Linux, gnu/linux, LearnLinuxTV, Learn Linux TV, LearnLinux.TV, Learn Linux, Linux Training, Linux Tutorials, Systemd, Init System, Init Systems, Systemd Tutorial, systemctl, systemctl command, learn systemd, systemd course, deep-dive, linux tutorial, command line, operating system, operating systems course, linux commands, linux command line tutorial, linux command line, systemd basics, linux services, linux tutorial for beginners, shell scripting, linux shell, linux essentials

Id: Kzpm-rGAXos

Length: 47min 40sec (2860 seconds)

Published: Wed Jun 21 2023