So I am running a lumen application which spins up processes.
these processes are meant to run in the backround and they run as a daemon, we send a start command to the api in php and that spins up the process using shell_exec, this used to be absolutely flawless but something strange has happened in later version of php / apache2 where the process is forked and completely dependent on either apache or php-fpm depending on what mpm module / webserver you're using.
this could be tested quite easily with index.php containing
shell_exec("screen -dmS testing bash -c 'while true; do echo test && sleep 1 ; done'")
Then restart php-fpm or apache
is there any way of stopping this behaviour? I have tried > /dev/null etc etc and with & at the end without success, I really need the process to not be dependent on php-fpm or apache2.
Related
Problem:
I am wanting to use php-cli scripts to quickly start, restart, or stop Apache 2.4 as well as MariaDB 10.5 on Windows 10. Several years ago, I did this while running Debian:
#!/usr/bin/php
<?php
system('sudo /etc/init.d/apache2 start');
system('sudo /etc/init.d/mysql start');
I would then execute the file by typing something similar to 'php -f .server.start' where .server.start was the name of the file containing the above php code. I have had some luck getting this to work by opening a command line, changing directories to C:\Path\to\Apache24 and using
<?php
system('httpd -k start');
The issue with this is I still have to navigate to that directory to make this work. The purpose is then defeated as I could simply type httpd -k start || stop || restart. I am using this machine at home for a dev box. There are times when I am interrupted for lengthy spans of time and I feel that I need a simple and quick way to shutdown both Apache and MariaDB with a command or two while I am away from my desk.
Perhaps PHP isn't the best solution here? It's what I know and am comfortable with, though, if there are other methods, such as with a batch file, I would be willing to accept any comments/feedback/direction. I have scoured the web trying to get this task done.
Webserver is configured as php-fpm pool per site configuration.
I am tryin to get my php "kind-a" asynchronous by using php
exec('bash -c "exec php index.php" > /dev/null 2>&1 &')
I am using successfully php apc cache but the cache of php-pool is obviously not shared with cache of above executed cli command. Is there any possibility to execute a php script with exec() IN the php-fpm pool from which the script is called by exec()?
An option like
exec('php-fpm --pool=domain.tld index.php')
I could not find any information about how apache calls a php pool process in a php-fpm pool configuration to get an idea of how it's done.
So my environment is Windows server 2008 R2 with php 5.3 and 5.5 installed. I have set fastcgi.impersonate =1 in php.ini, and added the IIS_IUSRS to the Administrator group (that is not permanent, it was just a temporary action to try and eliminate problems).
If I run:
exec('dir',$output)
$output shows what I would expect. However, if I run
exec('shutdown -s -f', $output)
I get nothing from $output, and the machine does not shut down.
No errors/warnings are reported either.
I have tried putting that same command in a .bat file and running
exec('shutdown.bat',$output);
but it produces the same results as running the shutdown command via command line.
If I run the shutdown.bat file by double clicking it, or if I type the shutdown command in a cmd window, the machine will shut down. So I know that command is good. Obviously there is a higher permissions issue that I am missing, but I have no idea what it is.
So, I found out through much trial and tribulation that (at least in server 2008 r2 w/IIS7 ) executing the shutdown command from fast_cgi or php is not possible. I only had to install apache and execute the shutdown command under it, and the command worked perfectly.
I'm running an Apache server on CentOS and would like to be able restart the webserver from a protected page using the following:
PHP:
<?php
ignore_user_abort(true);
shell_exec('sh sh/restart.sh');
?>
restart.sh:
service httpd restart
My question is if the web server shuts down and the PHP stops executing will the sh script continue running to bring the web server back online?
You should be fine since Apache doesn't shutdown until after the command is issued. But if you really wanted to be safe, use nohup:
shell_exec('nohup sh sh/restart.sh');
If your PHP runs as apache module, then once you kill httpd your script will be terminated instantly. So you need to delegate restart to i.e. command line script (called using exec() or shell_exec())
You might be able to add an & at the end of the command. This will fork the process and run it in the background. This way it will not depend on apache still running.
shell_exec('sh sh/restart.sh &');
If this works, you should not need ignore_user_abort().
I'm parallelizing a PHP script using Supervisor. When my script gets a certain response from the database, it executes a command to stop all the processes under control by the Supervisord daemon using supervisorctl. Here is the command:
// gracefully stop all processes in supervisor's group called processes
$cmd = 'sudo /usr/bin/supervisorctl stop processes:*';
exec( $cmd, $outputs );
The problem is that this command seems to have no affect when triggered from within a PHP script under Supervisor's control. Why?
If I start this group of processes running within Supervisor, and then trigger another instance of the script directly from the command line, it works and all the Supervisor processes are stopped.
What is going on? Can daemonized PHP scripts not exec() shell commands?
I checked Supervisor's log files and found the error message "sorry, you must have a tty to run sudo." From what I can figure, this is happening because Supervisor has daemonized my PHP scripts. Because of Linux security, I'm not allowed to invoke commands with sudo from within a daemonized process.
The solution was to run Supervisor as the current user, which is does by default, unless you execute it with the sudo command like I had been doing ( sudo /usr/bin/supervisord ). I was doing this because my scripts didn't have all the access they needed to run ( I guess I was lazy long ago when I set up my process ).
After fixing this, I could start Supervisor without using the sudo command ( /usr/bin/supervidord ), and then I didn't need to execute supervisorctl ( /usr/bin/supervisorctl ) with sudo to control it, thus solving the root problem of not being able to invoke sudo from a daeomonized process.