[Proposal] Run Scheduler tasks with the same instance of php with which it has been called

[ftbastler]

My server runs multiple versions of php which are called by php, php5, php7, php71 etc. When running code with the php command, it defaults to php 5.x, which has to be kept this way because of others projects on the server. As I run the latest version of Laravel, it requries PHP 7.1.x.

I can run the Laravel Scheduler by calling /usr/local/bin/php71 /path/to/artisan schedule:run with no problems when there are not commands scheduled to run. But here is the issue: Currently, when calling the Laravel Scheduler by the artisan schedule:run command, it runs the scheduled commands with the default php version (which is 5.x) so it runs into multiple syntax errors.

So how about running the scheduled commands with the same php instance with which the scheduler itself has been called? Or maybe specifyfing an option in the scheduler to run the commands with a specific php instance?

Thank you for taking this into consideration.

[fletch3555]

I don't see the issue here. You've already acknowledged the reason why artisan schedule:run uses php 5. Are you saying you expect it to magically know you want it to run with php 7.1? Calling the artisan script will automatically use the php executable found on the path, which you've stated is 5.x. The solution, as you said, is to explicitly call artisan with the php executable that you wish it to run under.

[sisve]

@ftbastler I believe there's logic already that attempts to resolve the current binary in different ways, and it falls back to php if all attempts fail.

1. Could you check the value of the PHP_BINARY constant? dump(PHP_BINARY);
2. Could you try specifying the binary you want with PHP_PATH =/usr/local/bin/php71 /usr/local/bin/php71 /path/to/artisan schedule:run to set the PHP_PATH environment variable?

It sounds like the PHP_BINARY constant isn't set for you, which is weird. If that's the case it then looks for a PHP_PATH environment variable. https://github.com/symfony/process/blob/master/PhpExecutableFinder.php#L54-L60

[mfn]

I'm with @sisve , it rather sounds like a bug. Laravel (or: symfony) tries to figure out the executable it was started with to re-use it exactly for these multi-version environments.

When you schedule commands with the scheduler, you use:

• \Illuminate\Console\Scheduling\Schedule::command which calls
• \Illuminate\Console\Application::formatCommandString which calls
• \Illuminate\Console\Application::phpBinary which calls
• \Symfony\Component\Process\PhpExecutableFinder::find which is were sisve pointed to

[ftbastler]

@fletch3555 Yes, I expect it to run any scheduled commands (that are ready and should be run) with the same php executable with which I called the scheduler itself.

@sisve @mfn Here is the output of calling the file test.php (which just runs echo PHP_BINARY;) with different php instances:

Sorry for the mess... ^^

[sisve]

This looks really weird. Can you look into the Application::phpBinary() and the PhpExecutableFinder::find() methods and check what they do? I wound presume, from your output, that it should work since PhpExecutableFinder checks PHP_BINARY, but I guess there's something weird going on.