Daemons and Horizon Overview 0:00If we're building an application that relies on a service to run indefinitely in the background, then we would need to create a daemon. A daemon, or sometimes pronounced as daemon, is a background service that runs a particular application for us and will automatically restart it if it stops. We can create a daemon within Forge through the Servers Daemons panel. And in the background, Forge is going to configure something called Supervisor to run the command for us. Now in our ZondaQuest application that we've been building and deploying, we've also installed Laravel Horizon. Horizon, if you're not sure, is a package from Laravel that manages our Redis queues Why Horizon Needs Daemon 0:31Laravel Horizon. Horizon, if you're not sure, is a package from Laravel that manages our Redis queues and also provides us with a dashboard to see how those queues are performing. Horizon also provides us with a command that spins up a long-running process, and that's what's responsible for running the different queued jobs. Now if we were to put the Artisan Horizon command into our deploy script, then our deployment would just never end because that Horizon command is running the long-running process. Instead, we would create it as a daemon. To create a new daemon, we need to go to the Servers Daemons panel. Now if we just scroll down and get this whole form on the screen, perfect. Configuring the Daemon 1:02To create a new daemon, we need to go to the Servers Daemons panel. Now if we just scroll down and get this whole form on the screen, perfect. So we need to specify a couple of bits of information, and although there's a few form fields here, Forge has already provided us with some common defaults. We do, however, need to specify the command because we need to tell Supervisor exactly what it is that it's running. In this case, we're going to do php 8.1 artisan horizon. This is the command that we need to run to start the Laravel Horizon. Next we need to tell it where to run this command. Now because this artisan horizon command is within our application, we need to give itNext we need to tell it where to run this command. Now because this artisan horizon command is within our application, we need to give it the directory of our site, home, forge, zonda.quest. But let's say we're configuring something like Sockety. Sockety is just installed globally on the server, so we don't need to specify a directory. Now we need to say which user is running this command. For horizon, it needs to match the same user that's running our site, so we will stick with forge. We can also specify the number of processes that Supervisor should spin up to run this command.We can also specify the number of processes that Supervisor should spin up to run this command. However, horizon is going to be doing this for us, so we can just leave this as one. Now we can also specify the number of seconds that the program must be running for before Supervisor is going to report to us that it's been successful. Horizon starts very quickly here, so we can leave this as one. Next we can say that when the command is told to stop, we'll allow it to stop for 10 seconds before Supervisor will just force it. So for example, our horizon command might need to close up some things, wait for some jobs to finish running, then close the connection to Redis, etc.So for example, our horizon command might need to close up some things, wait for some jobs to finish running, then close the connection to Redis, etc. That could take a few seconds, so we'll give it 10 seconds to stop for before horizon is just going to terminate it. And then finally, we can specify which stop signal to send when we tell Supervisor, stop running horizon. These are quite an advanced thing here, and so you should refer to any documentation of the command that you're using. Horizon is fine and will listen to a sigterm stop signal, so we'll leave it with that. And then we can create our daemon. Viewing Daemon Logs 3:09Horizon is fine and will listen to a sigterm stop signal, so we'll leave it with that. And then we can create our daemon. With our daemon now installed, Forge provides us with a set of utilities for managing it. The first thing we can do is see the daemon's log file. Now Forge has configured Supervisor to log any of its standard output into a certain log file, and then Forge is now displaying that content to us. Here we can see that the command is php 8.1 artisan horizon, and the output from this command is horizon started successfully. Now Forge will only ever show us the last 500 lines of log file. If we needed to, we could choose to clear the log file completely. Checking Status and Control 3:46Now Forge will only ever show us the last 500 lines of log file. If we needed to, we could choose to clear the log file completely. Next we can see the status of the daemon. Now this is what's going to show us the true representation of the daemon on the server. The status listed here only reflects any of the commands run through the Forge dashboard. That means if we were to SSH into our server and manually stop the Supervisor process, Forge wouldn't reflect that in the UI. Here we can see the command again and the status of this daemon. It's running, and here's the process ID, and it's been up for 2 minutes and 10 seconds. If we had configured the daemon to run multiple processes, then we would see each of those Editing or Deleting Daemon 4:23It's running, and here's the process ID, and it's been up for 2 minutes and 10 seconds. If we had configured the daemon to run multiple processes, then we would see each of those processes listed underneath. We're also able to restart, start, and stop the daemon. If we stop it, then the whole command is going to be stopped, and it will follow the same signal that we configured here, and it will allow for the number of stop seconds that we configured before the process is forcefully terminated. Next we can edit the Supervisor configuration file. This is the actual configuration for Supervisor that Forge has already generated for us. We can see here that it's also added some additional settings that we didn't need toThis is the actual configuration for Supervisor that Forge has already generated for us. We can see here that it's also added some additional settings that we didn't need to set ourselves. Any manual adjustments we make to this file won't be reflected in Forge. For example, if we were to change this command and save it, then Forge is not going to reflect this command in the UI. And then finally, if we no longer need the daemon, we can delete it. This will completely remove the configuration file from our server and also remove the daemon from the Forge dashboard.from the Forge dashboard.
