Stopping in-built php server on Mac Mavericks - Livecode - php

I'm developing something in Livecode and I have been experimenting with using Mavericks own in-built php server. I started the server by sending the following command through shell...
php -S localhost:8000
This enabled PHP to run successfully through localhost:8000/
However, I can not work out how to stop/disable PHP now in order to continue testing starting it - when I previously started PHP through the terminal I was able to do ctrl+c to stop php running but since I do not yet know how to do this through my app I get this error instead...
Failed to listen on localhost:8000 (reason: Address already in use)
Anybody know how I can stop it either via the terminal or through my Livecode app? Attempts to stop it through the terminal using just ctrl+c do not work

open a terminal and type:
ps -ef | grep php
it will list the php process with the pid (process id)
something like
$ ps -ef | grep php
501 14263 14133 0 10:25AM ttys001 0:00.21 php -S localhost:8000
501 14355 14265 0 10:25AM ttys002 0:00.00 grep php
The note the number for the line that lists your php process, the second column is your pid
in the example the process id us 14263, kill it:
$ kill 14263
do another ps
$ ps -ef | grep php
501 14358 14265 0 10:26AM ttys002 0:00.00 grep php
$
The process should not be listed anymore

Related

CentOS + PHP: Processes limited with shell_exec

I have a httpd process running (just apache2), with PHP. In index.php I have the following code in the file:
echo shell_exec("sudo -u apache python3 /root/folder/script.py 2>&1");
Which should execute a a program (which its doing nicely). The program takes ~40 seconds to return something, so it takes a bit. Ive created another python program which is multithreaded. Which makes a request 400 times on the same time to the url, which should start 400 processes.
When I run the command top -c, I see that the CPU is only at 9% while that should be higher. I tried the next command, ps xa | grep apache | wc -l. That returns 101 processes, I've done the command multiple times and its always at 101.
Before I did the command ps xa | grep apache | wc -l, I first made a mistake and tried ps xa | grep apache2 | wc -l, I don't run apache2, but that still gave me the numer 1. So my theory is that 101 - 1 = 100. Which is a too beautiful number.
So this should be some type of maximum / limit / cap. Where can I configure this?
Thanks for your time
===== EDIT =====
I think its queue'ing the requests, while when I login into the server and run the python script manually, the script just normally works without any slow downs etc.

Running backgrounded script from php exec / shell_exec call is now failing and re-spawning where before it used to work

There is a commonly discussed method of starting a background process in PHP using the exec or shell_exec functionality.
I have had success with this in the past with batch email sending, and sending data to APIs in the background.
In a PHP page that you would call by ajax, you do something like this:
echo 'process running';
shell_exec('/usr/bin/php -q path_to_background_script.php > /dev/null &' );
exit;
The background process normally runs as if called by the owner of the php user like a terminal process.
Recently however, under a FASTCGI system (ea-php56) I have found this method has stopped working.
Instead of one process beginning from one web-request to the calling page, I am getting the background script continually terminating and being re-spawned with a new process id. Interestingly, the only way to stop this continual re-spawning is to disable the line in the calling script that starts the process. The re-spawning stops immediately when you save the calling file without the call to the background script.
This tells me that it is actually the calling script (requested by the browser) which is actually being re-spawned.
This is what the re-spawning looks like from the root terminal. Notice the PID changes everytime I look:
[root#*** public_html]# ps -ef | grep php
*user* 725 1 7 23:53 ? 00:00:00 /opt/cpanel/ea-php56/root/usr/bin/php-cgi /home/*user*/public_html/background-script_exec.php
root 727 32411 0 23:53 pts/1 00:00:00 grep php
[root#dev public_html]# ps -ef | grep php
*user* 757 1 5 23:53 ? 00:00:00 /opt/cpanel/ea-php56/root/usr/bin/php-cgi /home/*user*/public_html/background-script_exec.php
root 759 32411 0 23:53 pts/1 00:00:00 grep php
[root#dev public_html]# ps -ef | grep php
*user* 781 1 12 23:54 ? 00:00:00 /opt/cpanel/ea-php56/root/usr/bin/php-cgi /home/*user*/public_html/background-script_exec.php
I have tried disabling "PHP-FPM service for cPanel Daemons". I have tried 'ignore_user_abort()'. fastcgi_finish_request() function is not available so could not try that. I have tried creating a shell script instead to call the background PHP script, which I call from the calling script - but this also does exactly the same thing.
Apart from disabling the ability to trigger background scripts from a PHP web-page, this new PHP FastCGI behaviour is creating an erratic re-spawning process that does not stop without intervention mentioned above. It has made shell_exec / exec functions unstable!
Problem seems similar to that reported here:
php exec/shell_exec/system/popen/proc_open runs calling script itself infinite number of times on linux
but, suggestion reported here does not help in this case.
This seems to solve the problem. Using the 'php5-cli' instead of 'php'
shell_exec('/usr/bin/php5-cli path_to_background_script.php > /dev/null &' );
I had early tried 'php-cli' and found it did not exist - I did not think to check to see that it was named differently!
If having similar problems, have a look for the php binaries:
>>ls /usr/bin/php*
>>/usr/bin/php /usr/bin/php5 /usr/bin/php5-cli /usr/bin/php-config /usr/bin/phpize
use the one which is for command line, and it should then run properly.
-note that this issue was specifically on a linux cpanel easy-apache fastcgi-php system running on Centos.

Artisan Error: Failed to listen on localhost:8000

I'm having a problem starting my Laravel installation. Whenever I type in the terminal php artisan serve, I get this error:
Failed to listen on localhost:8000 (reason:une tentative d'access un
α socket de maniere interdite par ses autorisation d'access a 0t0
tent0e)
What's the problem, and how can it be fixed?
img problem http://i.imgur.com/rOt3Lat.png
it's working now I just changed the listen port from 8000 to 8888 or any other port your services didn't use it
php artisan serve --port="8888"
Fixing Error: Failed to listen on localhost:8000 (reason: Address already in use)
List processes with php in it
ps -ef | grep php
Example output
501 **9347** 393 0 1:29PM ttys000 0:00.21 php artisan serve
501 9351 **9347** 0 1:29PM ttys000 0:02.01 /usr/local/php5-5.6.14-20151002-085853/bin/php -S localhost:8000 .../laravel/server.php
501 9781 393 0 1:56PM ttys000 0:00.00 grep php
Then kill the process
kill -9 9347
Are there any other services running on port 8000?
You can use this command on Windows:
netstat -aon | more
or on Linux / OSX
sudo netstat -plnt
to see what services are running. Then disable the service that is running on port 8000 or use another port.
List process using ps -ef | grep php
Then below only works for me
kill -9 9347
which is a force kill of the process
501 9347 393 0 1:29PM ttys000 0:00.21 php artisan serve
Option 2:
If above not works, Change the default laravel serve port number if you can, like
php artisan serve --port=8088
8000 is the default port. Use instead of :
php artisan serve --port=8005
It is because something already running on that port and you can change the port by command itself, by running following command
php artisan serve --port 8001
Use killall -9 php and if you want to close other services use killall -9 node or killall -9 mysql
When php artisan serve command given, below mentioned problem occured.
macridmi1109#Ridmis-MacBook-Pro kcnk % php artisan serve
Laravel development server started on http://localhost:8000/
[Thu Aug 6 11:31:10 2020] Failed to listen on localhost:8000 (reason: Address already in use)
Then try this line of code,
macridmi1109#Ridmis-MacBook-Pro project_laravel % ps -ef | grep php
Result will be,
501 66167 1 0 11:24am ttys002 0:00.77 /usr/bin/php -S localhost:8000
/Users/macridmi1109/Documents/Laravel/project_laravel/server.php
501 66268 64261 0 11:31am ttys002 0:00.00 grep php
Finally run the below code and, then again php artisan serve
macridmi1109#Ridmis-MacBook-Pro project_laravel % kill 66167
SOLUTION EXPLAINED BELOW
I use the command, ps -ef | grep php. After that, you will be able to find Process ID. After recognising the correct Process ID, use this command kill 66167 (kill "Process ID"). Then try php artisan serve. This worked for me.
Happy Coding😊
For me, it was silly mistake. I have installed php in new machine but php.ini was missing. So, I have created php.ini file from php.ini-production file and then php artisan serve command worked fine as expected.
for me php -S localhost:8080 from the terminal in vs code will sometimes crash, but still be running in the background.
-9 to force kill did it for me
thanks #hemss
I did
php -S localhost:8080
[Wed Dec 12 13:48:03 2018] Failed to listen on localhost:8080(reason: Address already in use)
then I..
sudo netstat -plnt
find the process running on port 8080
tcp 2 0 127.0.0.1:8080 0.0.0.0:* LISTEN 10312/php
then force kill it..
kill -9 10312
I get
[1] + 10312 killed php -S localhost:8080
then restart...
php -S localhost:8080
best way if you 8000 port is busy or you have more one project running is run your project in new port such as 8088 or another free port.
php artisan serve --port=8088
The solution I found a problem we face several times in Ubuntu.
*Failed to listen on 127.0.0.1:8000 (reason: Address already in use)*
What we do, we change the port, right?
This problem can be solved also in few seconds following below steps.
1. Open Terminal
2. **sudo su**
3. **netstat -plnt**
_find the process running on port 8080_
4. **kill -9 PROCESSNUMBER**
For more details, see my blog, click here
If you have all your configurations ok in the .env file then you should:
Use the answer from mayorsanmayor in this post to kill all php processes.
Then php artisan config:clear
Finally, php artisan serve
Good luck!

shell_exec not returning the same result as sudoed command line

I'm developping a PHP-FPM driven module in which in upload videos, then transcode them into several HTML5 formats in the background with ffmpeg. This PHP-FPM script runs under a specific, non-root UID, called tv25.
There is a variant in which I record a webcam stream through a Streaming Server (Wowza), which runs under the root UID, and launches the conversion through Java-written module.
In order to know the status of the processes I make a GET request to a script which runs the following function :
function is_conversion_running($base_file_name) {
$command = "sudo ps aux | grep {$base_file_name} | grep -v grep | wc -l";
$lignes = shell_exec($command);
return (bool) $lignes;
}
When I call this function through AJAX, it works for the PHP-FPM variant (the UID is the same, returns true while the conversion is running), but not with the Wowza variant (return false everytime).
The strange thing is that if I run the command in a shell, with the non-root UID, it works like a charm, since the ps command as been allowed to be run by this UID.
The problem seems similar to the one in shell_exec returns empty string, but the solution listed there doesn't work for me.
My /etc/sudoers line is like this :
tv25 ALL = (root) NOPASSWD: /bin/ps
Really can't figure out what is the deal...
What does the command return: 0 or NULL? In the second case the command probably failed alltogether. You can check with the exec function whether you get a non-zero exit code. Make sure to prefix your command with /bin/sh -c in that case.
PS: Do you really need the sudo for running ps? Normally you get all processes even without sudo.
Well I found another way to sikve my problem : since I want to know if the process is still running, I delegated the command in a shell script :
#!/bin/bash
BASE_NAME=`basename $0`
LIGNES=$(/usr/bin/sudo /bin/ps aux | grep "$1" | grep -v grep | grep -v $BASE_NAME | wc -l)
[ $LIGNES -eq "0" ] && exit 1
exit 0
And then I call it with passthru. Its return value parameter is then converted to boolean, negated, and returned by the function.
~

Getting following error while stopping apache

Stopping XAMPP for Linux 1.8.3-3...
XAMPP: Stopping Apache...fail.
apachectl returned 1.
XAMPP: Stopping MySQL...ok.
XAMPP: Stopping ProFTPD...kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
fail.
kill returned 1
i am getting the above error while stopping the apache please help me and i am using ubuntu
I had the exact same issue. Since you are getting an error stopping Apache and ProFTP only, you need to delete these two files:
/opt/lampp/logs/httpd.pid
and
/opt/lampp/var/proftpd.pid
When you delete the httpd.pid, Apache is automatically killed. And similar happens when you remove the proftpd.pid.
So now you can go ahead and restart the server and new fresh files will be created. :)
Delete the following files:
$XAMPP_ROOT/logs/httpd.pid
$XAMPP_ROOT/var/mysql/$(hostname).pid
$XAMPP_ROOT/var/proftpd.pid
When runningsudo /opt/lampp/lampp stop I get
Stopping XAMPP for Linux 5.6.30-1…
XAMPP: Stopping Apache…fail.
apachectl returned 1.
XAMPP: Stopping MySQL…ok.
XAMPP: Stopping ProFTPD…ok.
And when I open my browser localhost it’s not working
My solution it’s work for me.
run :
sudo rm -f /opt/lampp/logs/httpd.pid
Now restart xampp. You should not face this problem again.
Looks like the script is trying to stop the ProFTPD service but it is not running. The line:
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
Indicates that a kill command was issued with malformed or missing parameters. If you are not using ProFTPD, you can remove all instances of it in the startup and termination scripts.
The script that you are running is not only trying to stop the apache service but rather all the services that are related to XAMPP -
X is the platform - could be windows, linux or mac
A​pache
M​ySql
P​hpMyAdmin
P​hp

Categories