I've got such problem:
When I run script which uses pthreads extension, PHP crushes with this errors:
[notice] child pid 44688 exit signal Segmentation fault (11)
[notice] child pid 44689 exit signal Segmentation fault (11)
I have installed apache22-worker-mpm port, php5.4.16 with pthreads 0.44
Also command
ps -U www
provides such result:
PID TT STAT TIME COMMAND
44687 ?? TX 0:00:00 /usr/local/sbin/httpd -k restart
44688 ?? S 0:00:00 /usr/local/sbin/httpd -k restart
44689 ?? Z 0:00:00 <defunct>
44690 ?? S 0:00:00 /usr/local/sbin/httpd -k restart
Restarting apache - does nothing.
What can I do to fix this?
Thanks!
PS: on my Windows machine - all works fine, so problem isn't in php code.
The first step in investigating crashes is to obtain the stack from the core-dump.
Obtaining core-dump of Apache may be tricky -- because they are often disabled by default. But it can be done.
Now, the fact that it works on Windows is not, actually, proof, that it is not the php-code -- whatever the problem is, it may be triggered by the "just right" sort of racing between threads. The OS, the number of CPUs, and other factors all affect the results of a race...
And finally, are you sure, you are using thread-safe (zts) version of PHP itself?
Related
Currently I just use additional terminal tabs to manually start worker and clock processes in addition to an always-on apache proxying to php-fpm.
I tried heroku local when I started with heroku but its setup defeated me.
Now I want to give it another try.
I'm on High Sierra with homebrew php but have stuck with the mac os built in apache till now. It appears brew's apache may be a better choice but hopefully we'll find out if so in the following.
I realise from the answer provided here (by the top contributor to the buildpack) that the apache used by heroku local must be stopped at the time heroku local is started. There's a similar apparent quote from heroku support about this in an answer here.
I also note, my own discovery, that one should install the buildpack locally with * as in composer require-dev heroku/heroku-buildpack-php "*" to ensure the latest version.
Right now I get the following when I issue heroku local, using mac osx's built-in apache (I have it listening on port 8080 to serve my php dev environments, but stopped it for the purpose of this, with sudo apachectl stop).
m$ heroku local
[OKAY] Loaded ENV .env File as KEY=VALUE Format
12:21:03 PM horizon.1 | Horizon started successfully.
12:21:03 PM clock.1 | [2019-09-20 11:21:03] Calling scheduler
12:21:03 PM clock.1 | No scheduled commands are ready to run.
12:21:03 PM web.1 | DOCUMENT_ROOT changed to 'public/'
12:21:04 PM web.1 | 4 processes at 128MB memory limit.
12:21:04 PM web.1 | Starting php-fpm...
12:21:06 PM web.1 | Starting httpd...
12:21:06 PM web.1 | Application ready for connections on port 5000.
12:21:06 PM web.1 | [Fri Sep 20 12:21:06.155117 2019] [core:emerg] [pid 25867] (2)No such file or directory: AH00023: Couldn't create the mpm-accept mutex (file /private/var/run/mpm-accept-0.25867)
12:21:06 PM web.1 | (2)No such file or directory: could not create accept mutex
12:21:06 PM web.1 | AH00015: Unable to open logs
12:21:06 PM web.1 | Process exited unexpectedly: httpd
12:21:06 PM web.1 | Going down, terminating child processes...
[DONE] Killing all processes with signal SIGINT
12:21:06 PM horizon.1 | Shutting down...
12:21:06 PM clock.1 Exited with exit code SIGINT
12:21:06 PM web.1 Exited with exit code null
12:21:07 PM horizon.1 | [2019-09-20 11:21:06][1033] Processing: Laravel\Scout\Jobs\MakeSearchable
12:21:07 PM horizon.1 | [2019-09-20 11:21:06][1032] Processing: Laravel\Scout\Jobs\MakeSearchable
12:21:07 PM horizon.1 | [2019-09-20 11:21:06][1034] Processing: Laravel\Scout\Jobs\MakeSearchable
12:21:08 PM horizon.1 | [2019-09-20 11:21:06][1033] Processed: Laravel\Scout\Jobs\MakeSearchable
12:21:08 PM horizon.1 | [2019-09-20 11:21:06][1032] Processed: Laravel\Scout\Jobs\MakeSearchable
12:21:08 PM horizon.1 | [2019-09-20 11:21:06][1034] Processed: Laravel\Scout\Jobs\MakeSearchable
12:21:08 PM horizon.1 Exited Successfully
My mac os apache vhosts forward to /tmp/php72-fpm.sock. The permissions there are ok as apache in local browser reaches php-fpm fine.
I see that the actual error is (it scrolls off to the right in the code above due to no linebreak): Could not create the mpm-accept mutex. I now know there are a few different apache multi-processing modules, not sure if I need to know more about that.
But is that likely to just be permissions? I note mac osx apache needs sudo, as in sudo apachectl start and I am running heroku local without sudo. I could try sudo heroku local but would rather not until I know what it would do.
So in absence of more understanding here (which would be nice), I may trying installing brew apache (httpd24). It looks like heroku local will just call httpd, so, the one first in the path will be picked up.
Partial answer
I realised that when heroku local starts system apache, system apache will still have, of course, all of its current config. That means writing to sudo locations, error logs, vhosts which I have added. Of course, that's going to error without sudo. First step to fix the above was remove the listen directive from httpd.conf, which gave a new error:
(13)Permission denied: AH00091: httpd: could not open error log file /private/var/log/apache2/error_log.
So then I commented out errorlog to fix that one, which gave another:
(2)No such file or directory: AH02291: Cannot access directory '/usr/logs/' for main error log
2:17:25 PM web.1 | AH00014: Configuration check failed
2:17:25 PM web.1 | This program requires Apache 2.4.10 or newer with mod_proxy and mod_proxy_fcgi enabled; check your 'httpd' command.
Can see where this is going.
Basically, I would need to remove almost all of my mac osx apaches configuration for it not to error (when started without sudo).
So, let's consider brew apache instead... (below).
Of note, examining /tmp, each time I run heroku local I see the following files like heroku.xxxxx written as below of zero bytes. I note that the apache log files below can be found as Log directives in the default vhost include in the buildpack, in <buildpack>/conf/apache2/heroku.conf, hence their existence here.
mbp:tmp m$ ll
total 8
drwxrwxrwt# 16 root wheel 512B 20 Sep 08:54 ./
drwxr-xr-x 6 root wheel 192B 31 Dec 2017 ../
srwxrwxrwx 1 root wheel 0B 18 Sep 22:02 .dbfseventsd=
srwxrwxrwx 1 m wheel 0B 20 Sep 07:59 .s.PGSQL.5432=
-rw------- 1 m wheel 49B 20 Sep 07:59 .s.PGSQL.5432.lock
srwxr-xr-x 1 m wheel 0B 8 Sep 21:05 OSL_PIPE_501_SingleOfficeIPC_48607cb6b283d6f2d9ab5973acdb43c=
drwx------ 3 m wheel 96B 27 Aug 17:28 com.apple.launchd.9wuyYAXuof/
drwx------ 3 m wheel 96B 27 Aug 17:28 com.apple.launchd.v9lh33yWhI/
-rw-r--r-- 1 m wheel 0B 20 Sep 08:54 heroku.apache2_access.5000.log
-rw-r--r-- 1 m wheel 0B 20 Sep 08:54 heroku.apache2_error.5000.log
-rw-r--r-- 1 m wheel 0B 20 Sep 08:54 heroku.php-fpm.5000.log
-rw-r--r-- 1 m wheel 0B 20 Sep 08:54 heroku.php-fpm.5000.www.slowlog
-rw-r--r-- 1 m wheel 0B 20 Sep 08:54 heroku.php-fpm.www.5000.log
drwxr-xr-x 3 m wheel 96B 19 Sep 20:23 pear/
srwxrwxrwx 1 m staff 0B 19 Sep 22:11 php72-fpm.sock=
drwxr-xr-x 2 root wheel 64B 19 Sep 08:29 powerlog/
What else can I do to help the web process spin up?
Update - how to install brew apache for exclusive use of heroku local?
Perhaps what could be really useful is to know steps to install brew apache given that it'll be only used for heroku local. Is it a few simple brew commands and remove the listen directive? I'm cautious here as I would like ideally not to harm my current use of built in apache; these should be able to run alongside one another I think, just need to be reasonably sure before I do it.
Also
Homebrew now no longer supports options on formulae, so the brew install homebrew/apache/httpd24 --with-mpm-event as given at the link above
doesn't seem an option anymore. It is possible to do brew edit httpd24 to edit the formula directly; is that necessary? What are the correct install steps?
I'm posting a partial answer here which I'll update as I find out more rather than append this further information to the question itself.
I got it working with brew apache as follows:
brew install httpd
Edit /usr/local/etc/httpd/httpd.conf:
comment out line Listen 8080
comment in line LoadModule proxy_module lib/httpd/modules/mod_proxy.so
comment in line LoadModule proxy_fcgi_module lib/httpd/modules/mod_proxy_fcgi.so
comment in ServerName, I set it to ServerName localhost:5000
(this suppresses a complaint it will make - is that a correct value for ServerName?)
Edit /usr/local/etc/httpd/extra/httpd-ssl.conf as follows:
comment out Listen 8443
Don't do brew services start httpd, as you normally would for a brew service, that isn't relevant to us here.
(Now that we commented out the Listen directives, httpd won't respond anyway,
until heroku local starts it up and injects a Listen directive).
There is one area I don't fully understand yet.
When I run heroku local now, I can access my site at localhost:5000, but only the front page. Clicking on any subpage returns:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>
Perhaps we can fix that later. But let's consider php-fpm now.
Firstly, I had one easily fixable error, which is that heroku local was using mac osx's php-fpm (version 7.1 on my High Sierra), which I fixed by ensuring my php7.2 formula (which is keg only; I'll shortly move to php7.3) comes first in path.
Now which php-fpm returns /usr/local/opt/php#7.2/sbin/php-fpm and not /usr/sbin/php-fpm (mac osx built in). So, now we got it using the version we intend. Small but important fix.
However, we now must consider what happens when heroku local calls (i.e. starts up) php-fpm. Traditionally, I do brew services start php#7.2, which is always on (daemon). However, with Activity Monitor open, I see that heroku local spawns a new parent process and workers. Perhaps that's how it should be. It simply ignores the instance which is run by brew services, and creates its own.
The mystery arises though when I exit Heroku local by pressing Ctrl-C. Is that the correct way to exit it? If I do Ctrl-C, I get the command prompt back, but, looking at the spawned php-fpm processes in Activity Monitor, the php-fpm instances are not terminated. Then, if I issue heroku local a second time after stopping it the first, I get this:
5:44:37 PM web.1 | [20-Sep-2019 17:44:37] ERROR: An another FPM instance seems to already listen on /tmp/heroku.fcgi.5000.sock
5:44:37 PM web.1 | [20-Sep-2019 17:44:37] ERROR: FPM initialization failed
... which is quite understandable. That is fixable by manually terminating the process in Activity Monitor. However, I wonder what's happening here; what's the correct way to terminate heroku local?
To be specific, Ctrl-C quits a single php process which has a parent process of node, but does not quit five php-fpm processes, one of those five being the parent of the other four, and that one having a parent process of bash.
So, we've come a long way today; remaining issues seem to be; still to improve upon:
How to correctly terminate the php-fpm process (Ctrl-C doesn't do it).
Also if I have two terminals open, one which previously ran heroku local,
and I run it again in another window, the window which showed a regular command
prompt waiting for an instruction, suddenly jumps back to life, receives new
information, which is a but surprising, I wonder how that's working and if
that's considered normal.
Find out why apache isn't serving any page other than root as noted above.
It works!
Now we are motoring! The one important change I ommited in /usr/local/etc/httpd/httpd.conf was to comment in the line:
LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so
I'm using laravel which serves all pages via index.php. That means you want to rewrite every page request that is not to index.php back to index php. Thus, the default .htaccess in laravel has the line RewriteRule ^ index.php [L] which does just that...
Now the only problem remaining that I'm currently aware of is that Ctrl-C doesn't terminate child processes.... but first I'm gonna set all my local apps to use fpm 7.3, as I saw a reference in the buildpack specifically to 7.3, so wondering if that might help...
For some reason, drush is reporting successful upgrade of a core Drupal installation from version 7.56 to 7.58, however it is only partially doing the job! See below. Only updates a few files, should be a lot more than this as in all core modules/ files, as a minimum, it should update the version number.
After this, if I run drush status again it gives an identical report, so after it has told me:
Project drupal was updated successfully. Installed version is now 7.58.
I still see that we remain on 7.56. Any ideas? I have ensured that there are rwx permissions for the user over the Temporary file directory path and Drush temp directory and tested this with running touch to test can create and read a file. How can I debug/resolve this issue?
Here is another run of the update with the --verbose flag (for more info), which renders the same result. Still, I can't spot an issue here.
[rootuser]:public_html$ drush pm-update drupal --verbose
Executing: mysql --defaults-extra-file=/tmp/drush_XlJ3hK --database=myapp9name --host=localhost --silent < /tmp/drush_anVSdw
Executing: mysql --defaults-extra-file=/tmp/drush_bdl4sc --database=myapp9name --host=localhost --silent < /tmp/drush_Jr6xnY
Loading release_info engine. [notice]
Loading version_control engine. [notice]
Loading package_handler engine. [notice]
Executing: wget --version
Loading update_status engine. [notice]
/usr/bin/php /home/master/.composer/vendor/drush/drush/drush.php --php=/usr/bin/php [notice]
--backend=2 --verbose --root=/home/123456.myapps.com/myapp9name/public_html
--uri=http://default pm-updatestatus drupal 2>&1
Update information last refreshed: Wed, 04/04/2018 - 13:38
Name Installed Version Proposed version Message
Drupal 7.56 7.58 SECURITY UPDATE available
Code updates will be made to drupal core.
WARNING: Updating core will discard any modifications made to Drupal core files, most noteworthy among these are .htaccess and robots.txt. If you have made any modifications to these files, please back them up before updating so that you can re-create your modifications in the updated version of the file.
Note: Updating core can potentially break your site. It is NOT recommended to update production sites without prior testing.
Do you really want to continue? (y/n): y
Executing: svn info /home/123456.myapps.com/myapp9name/public_html/drupal-7.58
Executing: bzr root /home/123456.myapps.com/myapp9name/public_html/drupal-7.58
/home/master/.drush/cache/download/https---ftp.drupal.org-files-projects-drupal-7.58.tar.gz [notice]
retrieved from cache.
Downloading drupal-7.58.tar.gz was successful. [notice]
Md5 checksum of drupal-7.58.tar.gz verified. [notice]
Executing: tar -C /tmp/drush_tmp_1522848874_5ac4d46a6a4a4 -xzf drupal-7.58.tar.gz
Executing: tar -tzf drupal-7.58.tar.gz
Project drupal was updated successfully. Installed version is now 7.58.
Backups were saved into the directory [ok]
/home/master/drush-backups/myapp9name/20180404133418/drupal.
Command dispatch complete [notice]
/usr/bin/php /home/master/.composer/vendor/drush/drush/drush.php --php=/usr/bin/php [notice]
--backend=2 --verbose --root=/home/123456.myapps.com/myapp9name/public_html
--uri=http://default updatedb 2>&1
Executing: mysql --defaults-extra-file=/tmp/drush_ewbZAj --database=myapp9name --host=localhost --silent < /tmp/drush_KTg0dp
Executing: mysql --defaults-extra-file=/tmp/drush_Shazn8 --database=myapp9name --host=localhost --silent < /tmp/drush_RddgZd
No database updates required [success]
Command dispatch complete [notice]
Command dispatch complete [notice]
This was resolved by manually updating Drupal core using option 3, see below.
https://www.drupal.org/docs/7/update/core-option-3
There is that little matter of the "error_log" file. Perhaps the clue is in there...
Im developing simple (dead simple) front end for openwrt using PHP. To do this I need to call many openwrt UCI (Unified conf. interface) commands through PHP shell_exec() or system() functions. All the UCI commands that I tried in terminal are working perfectly fine. But as soon as I run them through above functions they are simply not working.
As an example I run following two commands which worked well in terminal
uci set wireless.#wifi-iface[0].ssid=test
uci commit
But as soon as I run them through PHP nothing happens. They are simply not working. The I make .sh file and save above two lines and run that files using PHP but again!! results are the same. But when I execute .sh file through terminal it works!!
For testing I set the both file permission to 777. but that doesn't helps. Is there are any additional requirements to run shell commands through PHP like root access to the PHP or Apache ? I'm new to this and I would thankful if someone can help
my apache error_log
[Wed Aug 19 08:26:53 2015] [error] [client 192.168.2.117] uci
[Wed Aug 19 08:26:53 2015] [error] [client 192.168.2.117] :
[Wed Aug 19 08:26:53 2015] [error] [client 192.168.2.117] I/O error
[Wed Aug 19 08:26:53 2015] [error] [client 192.168.2.117]
Im using apache as a web server and openwrt Chaos Calmer 15.05-rc3 as my base firmware on top of Raspberry pi 2
I managed to solve my problem using uhttpd web server instead of Apache. Apache somehow doesn't have enough privileges to execute UCI commands directly. uhttpd the default web server in openwrt can execute this commands directly
I tried to figure out the same problem and my conclusion so far is run php with root permissions. I know this is not secure, but at least it works. Here is one line from /etc/init.d/php5-fpm to run php-fpm with root privileges:
service_start $PROG -R -y $CONFIG -g $SERVICE_PID_FILE
The key flag here:
-R, --allow-to-run-as-root Allow pool to run as root (disabled by default)
Both answers are right. What sameera mentions was the fact that uhttpd has special rights running on LEDE or OPENWRT (as default), but what Anton Glukhov wrote is also correct, it allowed me to run as root but limited to avoid errors. I was not able to run my scripts (.sh) as with uhttpd, but php runs ok and does not have any bugs while running as root. I guess its a file permissions issue by default on Nginx with Openwrt. My solution was leave uhttpd running on a different port and run my program with all the rights and permissions while running everything else as non root in Nginx. Security is no issue in my case, its offline server.
service_start $PROG -R -y $CONFIG -g $SERVICE_PID_FILE
Works, in my case editing adding the -R flag in /etc/init.d/php7-fpm
I am trying to set up an upstart job but for some reason it stops immediately after starting
I'm on Cents 6.5 btw
here are my files:
/ect/init/test-daemon.conf
start on startup
stop on shutdown
respawn
script
sudo -u root php -f /usr/share/test_daemon.php
end script
/usr/share/test-daemon.php
<?php
// The worker will execute every X seconds:
$seconds = 2;
// We work out the micro seconds ready to be used by the 'usleep' function.
$micro = $seconds * 1000000;
while(true){
// Now before we 'cycle' again, we'll sleep for a bit...
usleep($micro);
}
I have then got this file: (which I found on a forum that logs events)
/tmp/log.file
debug/ (/dev/fd/10):19735:Fri Jul 25 11:52:40 AST 2014:Job
test-daemon/ starting. Environment was: TERM=linux
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
PWD=/ JOB=test-daemon
SHLVL=1
UPSTART_INSTANCE=
UPSTART_EVENTS=starting
UPSTART_JOB=debug
INSTANCE=
_=/usr/bin/env
debug/ (/dev/fd/9):19775:Fri Jul 25 11:52:41 AST 2014:Job test-daemon/ stopping. Environment was:
TERM=linux
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
PWD=/
JOB=test-daemon
RESULT=ok
SHLVL=1
UPSTART_INSTANCE=
UPSTART_EVENTS=stopping
UPSTART_JOB=debug
INSTANCE=
_=/usr/bin/env
debug/ (/dev/fd/9):19779:Fri Jul 25 11:52:41 AST 2014:Job test-daemon/ stopping. Environment was:
TERM=linux
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
PWD=/
JOB=test-daemon
RESULT=failed
SHLVL=1
PROCESS=respawn
UPSTART_INSTANCE=
UPSTART_EVENTS=stopping
UPSTART_JOB=debug
INSTANCE=
_=/usr/bin/env
in the log file, I get more debug information but its basically the above repeated a few times.
I get this from running start test-daemon which outputs test-daemon start/running, process 20600
I know the test-daemon.php doesn't actually do anything...at the moment I just need to get the actual job running, once thats fixed ill drop in my code
So from the above...is there anything I am doing wrong? as the job should only stop if I run stop test-daemon right?
Any suggestions would be much appreciated :)
Thanks,
Dave
I'd rather post a comment but with the low reputation limit I can not.
I am not familiar with this distro flavor but did you try to use nohup ?
Like this:
nohup php -f /usr/share/test_daemon.php &
It could be possible that detaching your command from the service process kills it.
Apache + PHP + Mysql + Linux
[notice] child pid 23145 exit signal Segmentation fault (11), possible coredump in /tmp
But nothing found under /tmp
How can i find the error?
Endless loop of the function in PHP code caused this error.
Check whether your PHP-FPM and PHP versions match. Make sure there is a (correct) PHP-FPM configuration corresponding to your PHP and PHP-FPM version, respectively.
PHP-FPM (config in /etc/php/7.0/fpm) and PHP versions may have gotten out of sync while updating. Updated PHP (/etc/php/7.3/) may cause apache child segfaults because of missing PHP-FPM configuration in /etc/php/7.3/.
See also “[notice] child pid XXXX exit signal Segmentation fault (11)” in apache error.log .