shell_exec doesn't seem to work on hosted server (Bluehost)

[KenHorse]

if(isset($_POST['clearflags'])){ 
   $output = shell_exec('php clearflags.php'); 
}

The above works fine on my local development server running Debian 10, PHP 7.4 and Apache 2.4.25. clearflags.php is a script that clears various fields in a MySQL database so it's easy to determine if it properly ran or not.

On my hosted server however (Bluehost), clearflags.php is never executed. My hosting service swears that SAFE MODE is not on in PHP (which is also Version 7.4). If I call from the command line (php clearflags.php), it runs fine.

$output on the hosted server is "Content-type: text/html; charset=UTF-8 " but nothing on my local server where the script is called and runs OK. No entry appears in the error log about this

I've also tried using exec() with the same failed result

Running phpinfo() on the hosted server shows that disabled_functions are "no value"

Thoughts?

Edited October 11, 2020 by KenHorse

[requinix]

Thoughts? Don't do that. Why do you have to run PHP code from a whole new process? It doesn't make sense. You're running PHP already so if you want it to do a thing then make it do the thing. Firing up new PHP processes for it is silly.

[KenHorse]

You'll note it is being called from a webpage button, hence the reason for calling it

Edited October 12, 2020 by KenHorse

[requinix]

Is that relevant? Is there something in clearflags.php that can only possibly work from the command line?

[KenHorse]

If that were the case, it wouldn't work on my Debian development server nor even a Raspberry Pi (also running its version of Debian 10), no?

 

But here's clearflags.php:

 

<?php
include("global.php");



//flag vars database entry as being sent			
$query = "update vars set changed = 0";
$result=safe_query($query);

//flag commands database entry as being sent		
$query = "update commands set changed = 0";
$result=safe_query($query);


//flag config database entry as being sent
$query = "update config set changed = 0";
$result=safe_query($query);


//flag config database entry as being sent
$query = "update remote set changed = 0";
$result=safe_query($query);

?>

global.php contains the MySQL logon stuff as well as the function safe_query:

 

host = 'localhost';
$user = '<user>';
$pass = '<pass>;
$db   = '<db>';
$charset = 'utf8';

// This part sets up the connection to the
// database (so you do not need to reopen the connection again on the same page).
$con= new mysqli($host,$user,$pass,$db);

// check connection 
if ($con->connect_errno) {	
    printf("Connect failed: %s\n", $con->connect_error);
    exit();
}

// This function will execute an SQL query against the currently open
// MySQL database. If the global variable $query_debug is not empty,
// the query will be printed out before execution. If the execution fails,
// the query and any error message from MySQL will be printed out, and

function safe_query ($query = "")
{
	global $con;
	global	$query_debug;
		
	if (empty($query)) { return FALSE; }

	if (!empty($query_debug)) { print "<pre>$query</pre>\n"; }	
	
	$result = $con->query($query)	
	
		or die("ack! query failed: "
			."<li>errorno=". $con->errno
			."<li>error=". $con->error
			."<li>query=". $query
		);
	return $result;
}

I've changed the db login info in this post for security reasons of course

[kicken]

Trying to run your other script with shell_exec just introduces unnecessary complexity to the problem.  Since your script is just another PHP script (and a simple one at that) then you can just include() it to run it.

if (isset($_POST['clearflags'])){
    include 'clearflags.php';
}

 

You shouldn't be messing with the shell functions unless you need to run some external non-php program or some other php application that's intended to be run standalone from the command like (ie, composer).

[KenHorse]

I understand but why would it work on my own development server but not the hosted one, especially since safe mode isn't on and neither exec nor shell_exec are disabled_functions?

[requinix]

Because PHP isn't installed as a command-line utility? Because it doesn't have the same extensions and configurations as the one running from the web? Because there are restrictions in place to prevent it from running correctly or at all?

[KenHorse]

It must be as I CAN run it from the command line, no?

phpinfo() doesn't report safe mode is on nor are any functions disabled

[KenHorse]

https://www.arcomcontrollers.com/phpinfo.php

[requinix]

12 minutes ago, KenHorse said:

It must be as I CAN run it from the command line, no?

Have you been able to shell_exec() PHP in some other way?

12 minutes ago, KenHorse said:

phpinfo() doesn't report safe mode is on nor are any functions disabled

Yeah, you've mentioned that.

5 minutes ago, KenHorse said:

https://www.arcomcontrollers.com/phpinfo.php

Lemme put this bluntly:

For most servers, PHP running a website and PHP running from the command line are two different things.

[KenHorse]

I understand that. Since clearflags.php is so small and only called from control.php, maybe the easiest solution is tol move the contents over instead of invoking a separate script....

[requinix]

Yeah.

[KenHorse]

Then again, adding

shell_exec=on in my php.ini fixed it....grrrrrrrr

 

I swear I tried that before....oh well

Edited October 13, 2020 by KenHorse

[KenHorse]

Thanks for the assist. Sometimes it takes a swift kick to get the brain cells working

[requinix]

There is no "shell_exec" php.ini setting. Not unless your hosting provider is doing something special.

I take it you're ignoring what kicken and I said and just going with what you thought the fix to what you thought the problem was?

[KenHorse]

Nope, I didn't ignore but using include introduced a different issue that was even  a bigger problem for me. In any case, it is running (and yes, I do believe the shell_exec setting must be something proprietary for them. I've noticed thaat Bluehost/Hostmonster and their myriad of spinoff hosting services do kind do things their own way but I never expected this to be an issue, especially as my scripts were working fine there a while ago (but I can't say exactly what that time frame is)