Systemd Timers

hello everyone i'm jacob calif and I'm the nerd in the street and today we are taking a look at system D timers alright everybody so if you've done any sort of Linux administration you've probably heard of something called cron there are a number of different demons out there programs that can run in your computer that exist to run other programs at certain times say you want to run a program at the same time every week or every 24 hours maybe you're running some kind of cleanup task rotating log files in my case I've been using timers recently because I've been setting up a system where every Thursday night I've been doing a live stream and I've got a stream server that I use as an RTMP restreaming server and it's also an HLS server and I spin that server up before the stream starts and then after the stream ends I destroy the server it's a digitalocean droplet that I'm using there and I can use digital Oceans API to actually create the stream server and set it up the way I want it before I start streaming and then after I stop streaming I can destroy that server just remove it from my digital ocean account and that way I only pay for the couple of hours that I'm actually using the server I don't have to pay for the full five dollars a month that it would take to keep that server running all the time so I've been using system D timers I set up a system on one of my other Linode servers that every Thursday an hour before the time that I start streaming it calls a script that spins up the digitalocean server so it's ready for me when I get off of work and I'm ready to start streaming and I don't have to worry about doing that manually because it's on a timer whatever the case is if you want to automate a process running automatically there are a number of different cron utilities out there that you can use however today with most desktop Linux distributions shipping with the system D I almost call that init software but I realized system D does a lot more than that freedesktop.org refers to system D as a suite so with most desktop Linux distributions shipping with the system D suite you don't actually need cron or cron D or @ cron or any of those alternatives to run things automatically if you have a program that you want to run at specific times or at specific intervals you can do that using something systemd timers now I like systemd timers myself in the context of I'm already running system D so I might as well use timers instead of adding another program running on to my system the initial setup for a system D timer is a little bit more complicated than a cron entry traditionally with cron systems you would have a single line of configuration you would put in a file somewhere with system D if we want to run a program we're basically going to have three different files that we need to touch the first one is a script file to actually run now if you've got a program that you're calling directly you don't need a script file you can just point to the program but in my case I usually want a specific script to run on a timer so we're going to make a script first then we're going to make a system D service to start the script and then we're going to make a timer to start the service so it's to system D unit files that will need but the reason I'm making this video is because it's really not as complicated as you might think if you've never done it before so I wanted to just show you the process in case you ever want to do this and without further ado we'll cut to the desktop alright guys so here we are on the desktop using a Fedora 32 virtual machine and we are going to keep it very simple today we are going to make a script file then we're going to make a system D service to start the script file and then we'll make a timer to run the service like I explained before so first of all the actual script file itself that we'll be running I'm going to make this inside of our /opt directory that's a good place to put third-party tools and scripts that you're running so I'm gonna put this and opt and I'm gonna call it my script dot SH and we'll open that up and we'll start it off here with crunchbang bin bash and this script is going to echo some text into a file just to make things easy for us to demonstrate here we're going to echo the date is and then we're going to run the date command so that the actual date will be echoed into this file and we are going to put that into home Jakub documents my log dot log so I'm currently signed in with the Jakob user and I want this to go just into a log file within my Documents folder so this script wouldn't be super useful in the real world but it is gonna be very useful for us here to verify that our timers working because when the timer gets called we should law the time and the date into our log file so I'll save that I'll close that and we do need to mark that file as executable so we'll do chmod plus x opt my script SH and then just to test that the script itself works we are going to open up our documents folder here you can see right now there's no log file but I am going to just run up my script SH and you can see it puts a log file in our Documents folder and that log file includes the date is and it's the current date I'm going to run that one more time and you can see that it is on every execution going to a pinned since I used to carrots in that echo command it will depend the date to the file every single time that that's run so that's working well I'm gonna throw the log file down in the corner here so next step we want to make the system D service that is going to call that script for us and it's going to be a very easy service to make we're going to put that a net C system D system and I'm going to call it my script dot service you can call it whatever you want it should probably have something to do with what the script is doing so inside of the script we are going to start off with our unit section and the only thing we need to put in the unit section is our description of the service I'm going to put description my custom script the next section we're going to put in here is the service section since this is a service file the type is going to be simple you don't actually need to put this line because the default type is the simple type which is basically just starting a process and then as soon as the process has started system D considers it's successfully executed it's not going to track how long it's running or anything like that I like to include the type even when it is simple just to make my files easier to read next exec start this is the file that we're going to call when we actually start this service and that's going to be opt my script sh and finally I'm going to put user equals Jakob so once again this is the current user name that I'm signed in as if I don't put user equals Jakob the script will run but it would be run as the root user since that's the default user to run system D services as that's not a security flaw because it requires root access to enable their start services so it makes sense that if you've got root access you should be able to run your services as root if you want to but in this case I want to be able to open my log file up I would be able to read it you if it was created by brute but I just want that to be owned by my user here for simplicity so I'm including the user line now if we were just making a system tea service and we wanted to run this every boot we could do that very easily if you want a log of every time your system boots we can put a little install section down here and we can say wanted by equals and then the target that we want this to be run with so if I put multi user dot target then this service when enabled would run whenever the multi user target is starting if I wanted to only run when I'm starting the GUI that I can put graphical target graphical at that target is what I normally use when I want services to actually run on desktop computers on startup but in this case we actually don't need an install section at all because we're not going to enable this service if we enable the service it would start along with a target but that's not what we want we want the service to start on a timer and in order to do that we need to have the timer unit in addition to the service unit so I'm actually going to get rid of the install section altogether and I'm going to save the service so that's all that our service file where there needs to be like I mentioned before this can seem overwhelming if you've never done it before but really it's seven lines of text we're only using four options here out of the many possible options that you can put into a service file so that's all we need to do inside of there at this point we can actually test that our service file is working by starting the service manually now we can't enable the service because it doesn't have an install section but we can start the service manually so I'm gonna do sudo systemctl daemon reload and that's going to scan for new and updated services and then I'm going to do sudo systemctl start my script daunt service I'm going to run that and you can see if I click into our log file down here it says log file is changed I'll reload it and you can see there's a new entry from 942 p.m. which is right now now it's 943 so we know that our service file is working now and all that we have left is to actually put the timer in place to automatically run that at the interval that we want so in order to do that we'll do sudo G edit let's see system D system my script dot timer now it's recommended that you name the service unit and the timer unit the same thing before the file extension it is not required and I'll show you how to not do that if you want to so our timer unit is going to look like this we still need the unit section at the top and once again we'll put a description and I'm gonna make the description the same my custom script and then instead of a service section and this file we're going to put a timer section since this is a timer unit now inside the timer unit if your timer and your service are named the same thing you do not need to include the unit option because it's going to default to running a service that's the same name as the timer however if for some reason you do want to make a timer that's named something different than the service then you can put unit equals and then I'm gonna put my script dot service and just like the type equals simple that I put in my service file even when I'm making timers that run similarly named services I still like to include the unit equals option just to make these easier to read if somebody's unfamiliar with system D and they don't know that a timer is going to automatically run a service with the same name then if they're looking at a timer unit they might be confused about its relation to the service unit so it's just an extra line of text that you can put in there to explicitly state when this timer runs we want to start this service next up we get to tell system D when we actually want this timer to run now we can specify a real point in time that it's going to run at or we can specify a time in relation to when the system was started so for instance if I wanted to start this timer five minutes after my system booted up I could put on boot SEC equals five minutes so that's going to wait five minutes after the system boots and then it's going to run the timer and then let's say I also want to run it every 15 minutes after that first run then I can say on unit active SEC equals 15 minutes so once again this would be the system boots up five minutes later this runs for the first time and then 15 minutes after that it runs again and then 15 minutes after that it runs again indefinitely so if you're doing something that doesn't actually have to do with the specific time of the day but you just want something to run every so often this is how you would do that now in my case like I said I want to run this every Thursday I'm gonna pretend even though this is just a script that's printing the date to a file I'm gonna pretend this is the timer that I'm setting up for the live stream service that I mentioned every Thursday that live stream that I do starts at 6:00 p.m. so I want to start the stream server up an hour before that at 5:00 p.m. just to make sure everything on the stream server itself is ready to go by the time that the stream actually starts so that means I want this to run every Thursday at 5:00 p.m. and in order to do that I'm going to put on calendar equals and the format that we're going to use here is day of week year - month - day hour minute second now this is one of those pieces of configuration that it's kind of arbitrary the format that we're actually using here it is logical it goes from least specific to most specific and so in our case once again Thursday I want this to run regardless of the actual date so I'm just going to put wildcards for the year month and day it doesn't matter what year it is doesn't matter what the actual date is if it's Thursday I want to run this service and then the time that we want it to run in 24-hour format so we're going to use 1700 hours now let's say that you want something to run the fifth day of every month if you don't actually care about the day of the week because the fifth day of the month might be a Tuesday might be a Monday might be a Saturday if you wanted to you could just put a five here in the date field and if I specify Thursday and the date of the fifth it's only going to run if it's the fifth day of the month and a Thursday which might not happen all that often if you don't care about what day of the week it is you don't actually put a wild-card here you just leave the day of the week out if you want it to run say the fifth of every month or every day of January of every year if I want this to run every single hour of every day of every week I could do that very easily but once again I'm just going to set this back to every Thursday at 1700 hours now when we're using on calendar for real times on the calendar we also have an option called persistent and this is a true or false I'm going to set it to true the default is false if persistence is set to true then if the system was turned off when this would have run then the timer will run the service on boot so let's say that I I'm wanting to run this at 5:00 p.m. on Thursday if the computer was turned off at 5:00 p.m. on Thursday and then I turn it on at 5:05 the stream still starts at 6:00 so I'm to run the service as soon as the system starts up so I would set persistence to true so that if the system was turned off at five o'clock and then I turned it on a few minutes later it would run the service so that's useful to have and then finally we want an install section here in our timer and I'll say wanted by equals I'm going to put timers dot target now this is a default target that's present on system D systems timers dot target is a target that starts up during boot automatically and timers dot target is a dependency of basic target so every time the system boots timers dot target is going to start pretty early on in the boot process it's going to start before multi-user target or graphical target if you wanted to you can make your timer depend on graphical target if you want the timer to actually start when the GUI starts so it let's say that you were using that on boots x equals five minutes if you have you're on boots x equals five minutes and you set wanted biographical dot target it's going to be five minutes after the graphical target starts whereas timers dot target is going to be five minutes after the timers target starts so probably a few seconds earlier and this is everything that needs to go into our timer unit so I can save that and I'm going to close it now two things need to happen for the timer to actually be active because right now it still wouldn't run at 5:00 p.m. on Thursday the first thing that needs to happen is we need to enable the timer so if I do a systemctl daemon reload and I forgot to use studio for that one so it's asking me for my password once I do that if I do a systemctl status my script dot timer you can see that the timer is inactive so it's not running right now and also it's disabled so it's never going to run automatically so what I want to do is a sudo systemctl enable on my script timer and I do have to specify the dot timer here if I don't it's going to default to my script service if I try and run this it's going to give us an error because our service file if you remember I did not put an install section in it if you did put an install section in it when you don't need it it wouldn't hurt anything once you get the timer set up but you might get confused if you accidentally enable your service instead of your timer so that's one of the reasons when I'm making a service that is only going to be called by a timer I don't put the install section in it so we need to run the enable command on my script timer and once we do that then we can run systemctl status my script dot timer again and you can see now it is enabled however at this point it is still inactive it's not running next time we start the computer when basic target starts and it starts up timers dot target then this timer would be running so I could reboot the machine right now or what would make more sense is just to start the timer with a sudo systemctl start my script dot timer that way I don't have to reboot and if I run systemctl status you can see it is active and it is waiting because the timer is not running right this second so at this point everything is set up and at 5:00 p.m. on Thursday this timer is going to start my service which is going to run my script now it's currently Sunday night and I don't want to wait for days to proceed with this video so what I'll do here is I'm going to open up the Nome clocks app just going to go ahead and add a clock here so we can see what our system thinks the current time is and I'm actually just going to change my systems time so that it thinks that it's 5:00 p.m. on Thursday that way we can test that this timer is going to work now if you just want to test if your syntax is correct for the on calendar command there's a handy command that you can use and that is systemd analyze calendar and then you put a string with your calendar event so Thursday every year every month every day at 1700 hours if I run that you can see it says from now three days left that's going to be the next time that this particular point in time is reached so I know that in three days I've got all my configuration set up the analyze command is telling me that this string is going to happen in three days and this is the string I used in the timer and the timer is waiting so I know that everything's going to work but just to actually see it in action I'm going to run sudo time date CTL set NTP false first to keep my system from automatically correcting its time after I change it here and then I'm going to run sudo time date CTL set time I'm going to set the time to Thursday 20 26 11 so that's this coming Thursday and I'm going to set the time to 1750 930 Mountain time so I'm going to run this and you can see our clock changed it's currently 1759 and at this point in within 30 seconds it looks like the system was trying to correct its time again but if I come over here to our log file and I click reload you can see we do have an instance logged ah I see what happened here so I accidentally put 559 p.m. when I should have put 459 p.m. because the timer set to run at 5:00 now because I had persistence enabled the system basically said okay well we somehow skipped over this time so we're going to go ahead and run the timer so that's why we have an instance of this timer running at 550 930 because it was supposed to run at 5:00 p.m. now I want to try and get this to actually run at the time that it's supposed to run at now looking at my logs here I'm not sure what actually changed the time back to 2206 after I said it we can see this is where I changed the time to 559 on Thursday the colonel sees that we changed the time and so does VirtualBox but by that point we had already changed it back all right so I'm just gonna go ahead and stop the service that is doing that then sudo systemctl stop VBox service dot service so hopefully now yeah that process is inactive and I'll set the time this time to 1659 so that's 459 p.m. on Thursday so I'm going to run this command and our time has been changed we can see in our log file that nothing has been changed yet because we have to wait the 30 seconds for it to tick over to 5:00 p.m. but as soon as that happens here you can see that our log file was touched again and now we have a new log entry for 5:00 p.m. right on Thursday the 11th so it's actually a good thing I messed that up the first time because that kind of shows us what persistence does and as you can see we now have a timer running that at 5:00 p.m. and every Thursday is going to run this script and write to this file so I hope this video was helpful to you guys I know personally I stayed away from system D timers for a long time like a lot of other parts of system D just because I thought they were kind of complicated I knew that I could use the functionality if I knew all the ins and outs but for a while I never took the time to just sit down and look how to actually do it if this video was helpful to you consider joining the nerd Club at nerd club Nance Co for just three dollars a month to help me make more videos but for now I'm Jacob calf and I'm the nerd of the street and I'll see you guys in the next one bye [Music]

Channel: Nerd on the Street

Views: 4,089

Rating: 4.9572191 out of 5

Keywords: nerdonthestreet, jacob, kauffmann, jacobgkau, Systemd, timer, timers, how to, tutorial, walkthrough, guide, set up, setup, cron, at, anacron, schedule, start on boot, start on schedule, Linux, automation, automatic, automatically, service, start services

Id: Oup21KLlpD8

Length: 20min 29sec (1229 seconds)

Published: Mon Jun 08 2020