Scheduler Panel Overview 0:00These days, it's common for modern applications to schedule jobs to run every minute, every hour, or even something super specific, such as every half-past-the-hour, but only on Mondays? You can easily schedule your own jobs through the Service Scheduler panel. Behind the scenes, Forge is simply managing the crontab configuration file for us. As we scroll through the Scheduler panel, we can see here that Forge has already added two scheduler jobs that we did not add ourselves. Now when Forge provisions a server, it will configure these two jobs for us. The first command that Forge will configure is to tell Composer to update itself, and it does this on a custom frequency, and in my case, this server is configured to run at 20 to 6 on an evening.it does this on a custom frequency, and in my case, this server is configured to run at 20 to 6 on an evening. Each server will randomly generate its own frequency, and it does this to prevent all servers from updating Composer at once and avoiding any accidental DDoSing of the Composer website. Forge also configures a command to automatically remove and clean any leftover dependencies that may be lying around since the server has updated itself, or we've installed additional software such as PHP. We can click onto the menu here, and we'll see three options. We can show the output, pause the job, or fully delete the job from our server. Creating a Scheduler Job 1:11We can click onto the menu here, and we'll see three options. We can show the output, pause the job, or fully delete the job from our server. If we show the output, we will see in this modal the command that we're running and also the output. Here we can see that we're already running the latest version of Composer. Nice. Now let's go ahead and create our own scheduler job. When creating a new scheduler job, we need to provide Forge with three bits of information. The first is the command, which is what we want to run. The second is the user who should run that command.The first is the command, which is what we want to run. The second is the user who should run that command. Then finally, the frequency, or how often that command should run. Since our application is built with Laravel, we're going to schedule the schedule run command, which is what this placeholder is suggesting here. When we click into the command box, Forge is going to suggest two versions of PHP that we can use. Now, PHP without the version number is the default CLI version configured on the server. We can verify which version of PHP is the default by going to the PHP tab and then scrolling down to PHP versions. Choosing PHP and Command 2:11We can verify which version of PHP is the default by going to the PHP tab and then scrolling down to PHP versions. We can see our server only has PHP 8.1, which is also the CLI default. Now a good practice is to always be explicit about which version of PHP is going to run our command. This means that if the server's default CLI version ever changes, our command will always run without being affected. In this case, I'm going to use PHP 8.1. Then I'm going to specify the path of my command, which is home-forge-zonda.quest, and then artisan, and then finally, I'm going to schedule the schedule run command.Then I'm going to specify the path of my command, which is home-forge-zonda.quest, and then artisan, and then finally, I'm going to schedule the schedule run command. I'm going to leave this as the Forge user, because that's the user who runs our site. Then finally, the frequency. With the Laravel scheduler, I'm going to leave this as every minute, because it's within that that we can configure how often our commands within our application should run. However, if I'm scheduling a different command that isn't using Laravel scheduler, I might need to get into a custom frequency. So here, every minute is bank on the minute, every hour is bank on the hour, every night is at midnight, every week is every Sunday at midnight, and every month is the first Custom Frequencies and Cron 3:17So here, every minute is bank on the minute, every hour is bank on the hour, every night is at midnight, every week is every Sunday at midnight, and every month is the first day of the month at midnight. Now the two that are a little bit more confusing are the onReboot and the custom options. When we use onReboot, Forge is going to configure a command that will run when our server restarts. So once it's finished initializing and everything is set up and the cron service is running, this command will be executed. And then finally, we have the custom command. This allows us to specify a very granularly controlled frequency that our command should run at.This allows us to specify a very granularly controlled frequency that our command should run at. It does this using something called a cron expression, and this is a way of representing how often a command should run. And here we can see that Forge is showing us when this command is due to run. So because this runs every minute, it's going to run at 12.04. We can change this to run only every hour, which is the same as the hourly command. Or we could say every 1 to 15. So between minutes 1 and 15, this command is going to run. We could say that this command can only run between the hours of 7 p.m. and 11 p.m.So between minutes 1 and 15, this command is going to run. We could say that this command can only run between the hours of 7 p.m. and 11 p.m. So we could do 19 and 23. And then we can see that this command will now run at 7 o'clock. Okay. For now, we're going to go back to every minute though, and we will then create our scheduled job. We can scroll down to see that our job is now being installed and is active. So if we immediately go and show the output of our command, it's unlikely that this command has got any output.So if we immediately go and show the output of our command, it's unlikely that this command has got any output. There we go. This job hasn't run yet. This is because the next minute has not yet passed. However, if we give this a bit more time to run and we wait a couple of minutes, then we'll start to see that the output is showing. There we go. This command is now running and we can see the Laravel output, running scheduled command, and we can see that it's running on the Amazon Inspire. Inspecting Server Crontab 5:24This command is now running and we can see the Laravel output, running scheduled command, and we can see that it's running on the Amazon Inspire. Nice. So how is Forge managing all of this? Well, if we SSH into our server, and then we clear this content, we can cut out the etc crontab file. Now when Forge creates these scheduled jobs for us, it's actually writing to this etc crontab file with all of the different cron expressions in. We view this. So the first thing we notice is that there is a provisioning cleanup script here andWe view this. So the first thing we notice is that there is a provisioning cleanup script here and Forge does this because anytime you run a command on your server through the Forge dashboard, it's actually uploading a bash script first, and then it's writing the output of that to a log file and Forge will clean these up every 30 days or so. And then beneath this, we can see the three scheduled jobs that we have in our dashboard. Now let's have a look at how Forge actually writes these. So first the expression, the user, and then the command that we're running. And we'll notice here, which we didn't put into our scheduled job, it's writing the output or piping the output of this content into this scheduled log file. Troubleshooting Cron Failures 6:25And we'll notice here, which we didn't put into our scheduled job, it's writing the output or piping the output of this content into this scheduled log file. And we can take a look at this log file by copying that path and doing a cat and we can see that command. So when we open the modal to show the output, this is the content that Forge is actually showing us here. Now for the most part, you'll find that scheduled jobs run without any issues, but occasionally you might find that all of your jobs will stop working for some inexplicable reason. Now usually this happens because just one command is not configured correctly. That's all it takes, one command and the whole Cron service will come to a halt.Now usually this happens because just one command is not configured correctly. That's all it takes, one command and the whole Cron service will come to a halt. Now often the reason for this is that the user you're trying to run a command as, so Forge or Root, that user no longer exists. And often this can happen when you have an isolated site and then you remove it, but the scheduled job still exists. So what you need to do is just make sure that those scheduled jobs are removed for any users that no longer exist on your system. Once that's done, the Cron will continue to work as normal.Once that's done, the Cron will continue to work as normal.
