How to Use Crontab Reboot to Schedule Tasks

Crontab is a Linux/Unix system utility to manage the scheduling of tasks. You can use it to specify which tasks run at which times, and create complicated rules for managing their periodicity. Here at SirsteveHQ, we’ve written before about how to create cronjobs, but the kind of cronjobs in that article, aren’t the same as the ones we’re talking about today. In this article, we’re talking about using the @reboot directive to schedule jobs when the server starts up. I’ll show you how it works, some examples, and when it’s unsuitable to use.

Can’t Use Cron to Reboot in Shared Hosting

It should be pretty obvious why you can’t use the reboot command if you’re using a shared hosting server. Your web host is hardly going to permit you to shut down the server for everyone else, so commands related to rebooting the system are almost always unavailable to regular users.

However, this doesn’t mean shared hosting users can’t use the @reboot directive. While the actual act of restarting a server isn’t available to you, you can configure your cron file to execute certain scripts when the system restarts. This is very useful for things like personal applications. Even though servers don’t restart nearly as often as user-level PCs, they do restart from time to time for maintenance reasons and if you want to ensure that certain scripts are always available, then using the @reboot directive is a perfect solution.

How to Use @reboot with Crontab

The crontab utility is command-line based, so the first order of business is to get access to the command line via SSH. Not all web hosting providers provide SSH access; some only give it when asked. SirsteveHQ is an example of a host that provides you with SSH access if you open a ticket asking for it.

So assuming you have SSH access, you can get started with using crontab reboot by typing the following into the command line:

crontab -e

The crontab utility solves the problem of locating the cron file, which might be in various locations depending on the type of Linux distribution and the specific configuration of your server. Like the “visudo” command, it’s a dedicated utility to modify a single file. When you run “crontab -e” for the first time, the system will ask you which editor you want to use. I prefer “vi”, but you can press the number that corresponds to your choice. The next time you issue the same command, the system will remember your choice and open the editor immediately.

One of the problems with editing crontab is that your editor might use a color scheme that’s extremely hard to read on a dark background. For example, this is what I saw the first time it opened:

To make crontab more readable, type the following:

:colorscheme desert

This will change the colors and make it look like this, instead:

So much better, right?

Adding a @reboot Directive

To implement crontab reboot, simply add the following line to the bottom of your crontab editor:

@reboot /path/to/script_or_command

Replace the “/path/to/script_or_command” variable with the actual path to your script, save your changes, and you’re done! Now whenever Linux restarts, it’ll go through your cron file and execute the commands contained one by one.

No Need to Restart any Process

After you save your changes to the cron file via crontab, the process automatically notifies the cron daemon, which takes into account the file changes without any further action on your part. It also means that anything you’ve removed will no longer be executed, effective immediately.

The Most Appropriate Processes to Use @reboot For

If you’re an administrator of a Linux server, there are many options to choose from when it comes to starting a script or a service after a reboot – crontab is just one of the tools. If, on the other hand, you’re a user on a Linux server – especially on a shared hosting plan, then you have no choice but to use the crontab reboot option.

Here are some of the processes and scripts for which crontab is most suited. These processes are characterized by a lack of dependencies or system-level integration.

Data Backups

Data backup scripts are particularly well suited to a crontab reboot directive because they can be run in isolation and don’t need to depend on any other scripts. In addition to running these scripts on reboot, you can use crontab to schedule them at other times of the day as well. Both database dumps and file backups are well suited to this kind of scheduling.

Log File Maintenance with Crontab Reboot

Linux has tons of log files, and it’s a headache to keep track of them all. Some, if you don’t pay attention, will continue to grow and can end up strangling your server for space. It’s a good idea to get ahead of this and regularly compress your log files, initiate new ones, and perhaps even delete a few that are no longer required. This is another example of a process that is well-suited to crontab, and you can initiate the process after a reboot.

System Health Checks

After a reboot, it’s a perfect time to perform some quick health checks. Make sure that the applications are running smoothly, ensuring that critical services are still ongoing, and making sure that your sites are up and running. This kind of standalone process is ideal for inclusion in crontab after a system reboot. In addition to the reboot you can, of course, schedule these checks for future intervals.

All of the above processes are perfect for crontab. However, there are many processes for which it’s unsuitable. Here’s why.

Processes That are Unsuitable for Crontab Reboot

If you notice, in the above list I haven’t mentioned any “important” services like databases, web servers, or processes dealing with system-level services. That’s because crontab is best used when the process in question can be started independently of others. If you want to start a web server, for example, then you should first make sure that your database service is up and running, which in turn, would require some other service to run. If your process is deeply integrated into the fabric of the server, then it’s best to use another tool like systemd.

When reading Linux guides about services, you’ll often see a command that looks like this:

sudo systemctl enable [service-name]

Where “service-name” refers to the service in question. For example, a web server might be “httpd” or “apache2”. Systemctl is the tool used to access the systemd subsystem that powers all the important, integrated processes in Linux. Note that you would never want to start your web server using a crontab reboot! That’s because systemd ensures that the processes start in appropriate ways, with all existing dependencies.

In short, crontab reboot processes are more “standalone”, while systemd processes have a lot more going on behind the scenes. But if you’re a user in a shared hosting environment, you don’t have to worry about systemd or systemctl as you won’t have the necessary permissions, anyway. For you, crontab reboot is all you need, and you should get as familiar with it as you are with regularly scheduled cron events.