• Servers and Tools

Manging a Service

From the class:  Managing Processes with systemd

Now that you know how to use the journal, let's play around with sending signals to our process through system D. So up top, what I'm going to do is to follow the journal for our specific service. So pseudo journal control dash f and then dash u. It looks a little bit funny. But this will give us a tailing of the log, so we can see what's happening in real time.

Now down below, let's try stopping the service. So I'll say pseudo system control stop hello. And notice that it prints out up top that it received the terminal signal. So it received the terminal signal from system D and then it stopped.

So this happened automatically. System D actually sent this terminal signal. Remember, we didn't actually write that into directive. It just does this automatically when we say to stop one of the services.

Now let's start it back up again. So I'll use the start command system control start. And it boots up right away. Now let's try reloading the service. Remember, this is going to send a USR1 signal.

And we define that in our unit file configuration. And sure enough, it works fine. So the process or the code receives this USR1 signal. We write out to the console that we got it, and then we proceed along as usual.

Remember the restart always option? Let's make sure that it actually works. I'm going to say system control status hello to so that we can get the process ID. It looks like it's 8532. And what I'm going to do is to kill that process manually, So I'm going to say pseudo kill 8532.

Looks like it died. But then it just starts right away. It's automatically restarted for us. So we have a little bit of a safety net here. And notice the line. It says service hold off time over, scheduling restart. So what it's doing is it's saying, have we reached the limit, the limit of the number of times we're willing to restart the service within a 10 second period or some interval of time. And let's try killing it a bunch of times.

So let's see. I'm going to use pkill this time to just kill any Ruby process so that I can do it quickly. So I'll say pseudo pkill Ruby and it dies. And I'm just going to do it a bunch of times. And notice that after a certain number of times, system D just gives up and says, we can't restart the service. And here's this big red line. It says, fail to start the service every 5 seconds because it just reached the limit.

It tried to start the request. It repeated too quickly and it finally gave up. And that's generally what we want, because if you have an application that is erring out and it just reloads, reloads, reloads, reloads, reloads, you can fill up your log files, run out of disk space, and it's a big nightmare. So this is a nice safety net.

If we take a look at the status of the service now by using the status command, it'll show us that it's in a failed state. And so if we want to restart it, we can say pseudo system control start. And then it'll start up just like usual. So that's it. We've created our own custom service for a program that we wrote in Ruby.

But we could have written the program in Node.js or Python or in C or anything else, as long as we have a program executable that we can give to system D to run. And this makes our lives a lot easier when managing a bunch of different disparate services on our servers.