Run PHP script on schedule cron. When it's not so clear

In this article I will talk about some of the subtleties of running php scripts on hostings, the ignorance of which can ruin a lot of nerves to both novice programmers and medium-sized masters.
The reason for writing this article: problems running scripts on hosting with different settings. And since the settings may be different, the information given for general cases may not be appropriate and mislead.

A bit of theory on these links: here and here , for those who want to refresh their memory.

Case one

The default paths are not specified in the operating system settings. As a result, the following command in cron will not be executed.
')

php /var/www/LOGIN/data/www/SITE/cron.php 

The correct command is the second option, where we prescribe the full path to the php interpreter.

 /usr/bin/php /var/www/LOGIN/data/www/SITE/cron.php 

There are several more ways to run the php script described here . What is interesting here is that the php script runs as a file with commands for the console and here you can write a whole cloud of commands and describe all sorts of options for every taste. The code looks like this.

 #!/usr/bin/php <?php ?> 

The command for execution in cron is prescribed the path to the script and only. The script puts the characters #!, And then simply write the commands we need in the bash language.

Case two

Running the script when requested from the browser results in the output of the page to the browser. And when executing the script via cron, it displays the text of the page on the command line. There may be several options. The system can be configured to save the output to the console as a file. And this file may not be placed in the most typical place. Gradually, this can clog up all the disk space. Often, under the site give a place in 1 GB, 500 megabytes. And even met hosting with 50 and 10 megabytes for the site.

As an option, the output can be redirected to the mailbox, which the careful hosting provider unobtrusively presented to you and registered in the hosting settings as the default email. Each time the script is executed, all text displayed in the console will be in a letter. Problems can start unexpectedly. If the cron job is performed frequently, and the hosting mail has a limit on the number of emails per day, the mail will simply fall down (blocked by the provider as a potential spammer). And how unpleasant consequences you will get a refusal to register users, notify users, etc., that is tied to mail.

The decision is as old as the world. You need to redirect the output from the console to the void. This is done by adding a command at the end of the crown command.

 >/dev/null 2>&1 

Sometimes hosting admins take on the responsibility of unobtrusively putting them for the user. There may also be an underwater rock.

Case three

The situation is simple. You need to debug the script that is run by the scheduler. You can try to do this using php, force the script to write logies, etc. But there is a way much easier, you need to redirect the output to a file. The command is simple, an additional parameter to our team:

 > /var/www/LOGIN/data/www/SITE/log.html 

It should be added at the end of the command:

 /usr/bin/php /var/www/LOGIN/data/www/SITE/cron.php > /var/www/LOGIN/data/www/SITE/log.html 

The “>” sign tells the system to redirect the output. Next is the file name. In our case, the absolute path is indicated. This example is easy to find on the Internet. But here we can face the trouble resulting from the second case. The caring hoster automatically adds output redirection at the end of our line. And sometimes it masks it. The result is a command like:

 /usr/bin/php /var/www/LOGIN/data/www/SITE/cron.php > /var/www/LOGIN/data/www/SITE/log.html >/dev/null 2>&1 

As a result, the output is redirected to void again and the output file will be empty. Here the hoster can point to his mistake, that he too outwitted the settings. And you can immediately use the crutch. After the redirection command to the file, end the command with &&. These two characters are used on the command line to combine several commands on a single line. They make the command line understand that the command is over and the next command goes on. Redirecting to void is applied to it. As a result, the redirection to the void remained and the log file was recorded correctly. Command example:

 /usr/bin/php /var/www/LOGIN/data/www/SITE/cron.php > /var/www/LOGIN/data/www/SITE/log.html && >/dev/null 2>&1 

The fourth case

The script has started, but it does not work correctly. The reason for this is that the php interpreter, when started from the command line, starts working in an improperly configured environment, different from the one that would have been started via an HTTP server. The first sign is that the script does not find the files that lie with it in the same directory, but begins to consider itself located in the root directory of the user, which is several folders higher than the site root. The first thing to check is the variable environment and the super global $ _SERVER array.

The first thing that you find on the Internet for this problem is the advice to register in the crown a command for changing the directory:

 cd /var/www/LOGIN/data/www/SITE/ 

But in some cases it does not help. There is an exit. One of them will take everything into his own hands and set the missing environment for the script. Information about this on the Internet is more.

Sometimes it’s just enough to write the following code at the beginning of the script and the paths become working again.

 $path_parts = pathinfo($_SERVER['SCRIPT_FILENAME']); //    chdir($path_parts['dirname']); //     

As you can see, everything is spelled out with functions and you don’t need to bother with the settings.

Conclusion

That's all. Problems and solutions are not trivial, and in general such a combination of unsuccessful settings is rare. Good luck when you deploy your projects and when moving.