systemd on Linux 1: Intro and Unit Files

what's going on everyone in this video i'm going to cover kind of the basics that you need to know about systemd both theoretically and practically like how you're going to be interacting with systemd when it is your system's init process firstly what is init i'm just very quickly going to cover that we're going to talk about how systemd kind of works the main ideas that you need to know to work with systemd we're going to cover units we're going to cover systemctl we're going to cover systemd targets and we're going to cover kind of the relationships between different systemd units what you might think of as services right now and how systemd handles dependencies and execution order you're also going to get all the ingredients that you need to like make a service in systemd and manage it so long story short init is a special process that is started by the kernel it's a special process because it's the first process that really gets started by the kernel during boot the process id or pid is one and it's a process that not only is it responsible for kind of booting the rest of the system and getting the system to a state where things are working people can log in et cetera but in addition to starting services and getting the system there it's also a long running process that kind of has some power over other processes for example when a process is orphaned because its parent process dies um it is re-parented under init so it's kind of the ultimate mommy on the system it takes care of orphans it kills zombie processes it's kind of responsible for process stuff that can go wrong during the normal operation of a system init used to be a series of plain text scripts essentially in etc or etsy init.d that's what's known as sys5 style init or you might see it written as sysv style in it that's kind of the older unix way of doing it you have a bunch of plain text scripts that get run essentially in order the user can kind of mung that order around but long story short there were some drawbacks to that and systemd has kind of replaced how that works in linux it is not a unix uh init system it is at this point purely in linux so really when you think of system do you think it's init but it also kind of handles all system state and service stuff during boot and then during the time that that system is up and running what is systemd it's really a collection of programs and libraries it's not even just one binary you have the systemctl commands for interacting with it you have journal ctl you have a bunch of tooling around that um in fact it does so much more than it it's sort of an agglomeration of process management network management through network d logins through logind and logs that your services then emit through journal d and those are no longer plain text logs they're they're binary files which has some advantages and some disadvantages so it's a bunch of stuff and that's what you have to know about systemd before you actually start using it systemd units uh what is a systemd unit well a unit is really what you might have called a service before on an older style of in it it's a unit is any entity managed by system d and that can be a bunch of different things yes it's services for sure so it's programs that run you know that are long running that are run as a service it can also be socket files that like need to exist for something it can be devices you can have a system to unit that kind of defines a device and needs to make sure that that device is there in the right order it can be a mount point or an auto mount point it can be a swap file it can be a partition it can be a startup target which we'll talk about a little bit later in a separate section targets are basically they're kind of the systemd equivalent of run levels but they're named so they're kind of like a named run level it could be a watched file system path you can define that as a unit that lets you manage something like saying oh you know my console service unit can require a file system path like opt console if that's on a shared file system or something like i can require that that's there before i start my service comes in handy and lastly it can be a group of externally created processes which we're not going to get into in this video long story short it's much more than just service management it's dependency management and requirement management and target management of all kinds of different entities let's talk about where these unit files are actually kept there's a few different places lib systemd system is where your kind of standard default unit files are kept this is like you boot your system the first time this is what your distro people creators put in place there there's user lib system d system which as you might guess from user lib that is where locally installed packages like after the first time you booted the system you installed some packages if they have systemd unit files that go along with them that's the canonical place to put those so put there by your package manager or more realistically that your packagers for your software there's run systemd system for transient or temporary files i'm listing it not because i've used it but only because it's part of the official documentation and finally and this is the really important one for you is etsy systemd system etsy systemd system has all of your uh kind of locally configured uh stuff you can see it has the the targets there so if you're manually creating a systemd unit file for this system this is where you put it you put it in here so you would you know have it be at etsy systemd system i don't know console.service for example for the record etsy has the highest priority so it also overrides things in the other kind of locations let's write a very basic systemd unit file just so that you've seen one we're going to go into the details of this much more later but if you wanted to write an extremely simple system to unifile here's how you would do it you would because it's a custom unifile it goes in etsy systemd system and then whatever your service is called uh service and it's a service so we'll use that file ending i'm just going to write this quickly and then talk you through it so we have a unit section that can contain a description and some other stuff about this unit file specifically maybe in our case we'll have a network service so we'll say after the network is up we'll talk about targets a little bit later we're going to have a very simple service section that just has an exact start defined with just the path to my program we're just going to assume that something like that is there and then start it and we're going to assume this is a server and it's going to target multi-user by default so basically when the system is up and multi-user login is available like the state that a healthily booted linux server is in we want this unit to be included in that so you're not finished booting until you've done until you've started this unit we're going to go ahead and save that and you'll notice that you can't actually find this oh my god did it automatically load that's incredible um i'm used to having to do and it's i think it's still a good practice to do systemctl daemon reload and what that does is it makes system d re-read all unit files so they get reloaded re-parsed by systemd it does not restart units so if you change uh like if i make some changes to this while i'm kind of building and troubleshooting and starting it and testing it doing you know making updates and then doing a demon reload would not restart that service so it would still have the old config so make sure that you do a systemctl restart your service name if it is if you want it to kind of re-read the new unifile config but that is a very very simple service that is valid as long as long as you have this dave program which i do not have on this machine but it could even just be a script so let's inspect the unit file for nginx to do that we're going to just look at the status of nginx we know it's registered with systemd that is loaded and that gives us a path to that unit's unit file in this case it's in lib systemd system this saves you because there's four or five locations where systemd likes to put things or unit files um this is the easiest way to to find something so now we can just use less to inspect that file and we can start looking at it now the syntax it's a really simple uh almost like i don't know is this sort of an any file syntax comments are hash marks just like in any bash script and so this is all pretty self-explanatory there's nothing super complicated in these although there are a ton of options like this is only a small amount of options this is i think a good example to kind of look so you have some comments here about what signals nginx will uh respect and how it will behave when you send different signals to it i'm not going to go through all this for because we're not learning about nginx here but this basically says hey look i'm defining a new systemd unit it takes a description this is optional and here's here's the important thing this says and we'll talk about this a little bit later this just says this unit should come up so systemd as you're booting if this is enabled bring it up only after the network target has been reached so only after we have networking does it make sense to start network services like nginx right it's a web server now in the service section you can kind of specify what what type of process this is going to be which kind of means how it's going to be managed in this case it's type forking which means the main process is going to start because nginx needs to bind to port 80 which is a it's one of the first 1024 ports which means it's a privileged port which means it needs to be run or open by root so nginx starts with more privileges grabs the port forks and creates child processes that are actually going to handle traffic and then you know with lower privileges once it has that port it doesn't need those privileges to open new ports anymore and the main process the process you started exited and then you have child processes anyway it's it's one very common type of kind of service canonical way of doing a service in linux so here you have a type forking which means hey the the process you start isn't going to be around even though nginx will still be up so don't expect the main process to stick around it'll exit and then this is the second argument that goes with a forking type where well fine if if the main process if systemd can't depend on the main process that it starts continuing to be up how does it know well it knows because nginx promises to put a pid file into run nginx dot paid little linux trivia there for you you can execute things before the process starts yeah you usually want actually i think you even need an exact start directive here where it's like what is the command for actually starting this service you can tell it's just this is just how you would execute the binary from the command line right here's uh this is optional if you send a reload system ctl reload how does engine x behave well what command gets run you can see it's just it's just running the command again with some different um options in this case nginx knows about a reload so you can just do a s reload and then exec stop systemd will try a few things to stop a process but if you have a way of cleaning up or a special option or something you can see there's this s-pen start stop daemon that it uses this is this is how the creators of nginx or at least the creators of this unit file want nginx to be stopped so that's what you again this is optional finally the install section tells us or tells systemd really when at what point should this unit be running what wants this so this is like a realistic i mean very realistic it's one of the most popular linux services there is unit files i think it gives you a good example of a lot of stuff including comments and like weird kill behaviors or signal behaviors but not all of these things are required so now that you've seen all this and you know this basic theory you are ready to learn about systemctl the actual practical command for working with systemd

Channel: tutoriaLinux

Views: 23,638

Keywords: computer, how-to, Linux, tutorial, system administration, sysadmin, command-line, CLI

Id: N1vgvhiyq0E

Length: 13min 48sec (828 seconds)

Published: Sat Jun 26 2021