From time to time my Apache server logs this error
[Sat Nov 07 05:35:01 2009] [notice] child pid 2795 exit signal Segmentation fault (11)
What may be the reason behind the error?
Thanks!
Perhaps it helps to reduce the value of MaxRequestsPerChild in your apache2.conf. In addition, it might be helpful to disable all Apache modules you have no need for.
Looks like you are running a cgi of some sort that is segfault under certain conditions. Check what cgi's you have and then test them. Most likely they will be a C or C++ based cgi, since it's a segfault, but no guarantee.
A segfault basically is caused by an attempt to access memory in a non-authorized way. To determine where the problem occured, a core file can have been generated on your system. If necessary the system has to be configured to get those files, but this depends on your system ; see coreadm(1M) for instance.
Once you get the core file you can get the stack trace of the process that caused the fault with an utility such as pstack, and many more with a debugger.
Related
I've read numerous posts about Semaphore issues, but none appear to be related to this particular issue. I am running Apache 2.4 and PHP 7.1 as part of Zend Server CE, and when starting the Apache service, the following fatal error shows up in the Apache error log:
ZShmStorage(): Fatal error: failed to allocate semaphore. Permission denied
I'm guessing that is related to shared memory storage, but I'm unclear ...
what it is actually trying to allocate the semaphore for
where to look for configuration relating to said semaphore
I thought maybe it was related to the Zend Cache, so I made sure that the permissions looked correct for the [ZendServerPath]/tmp/datacache.
I also thought maybe it was related to the PHP Sessions, so I made sure that the directory specified for the session.save_path in the [ZendServerPath]/etc/php.ini file had proper permissions as well.
I'm unsure where else to look, as there doesn't appear to be any discussions (that I've found) relating to this, but instead it's all about available space and whatnot. In the off chance that it was related to something that borked during allocation, I went ahead executed ipcs -s and noted that there were ~20 Semaphore Arrays present while the Zend Server was running. I stopped the service and ran ipcs -s again -- no Semaphore Arrays were left lingering. Restarted the Zend Server service and the error was encountered again and ~20 Semaphore Arrays were also reallocated.
Any assistance or info to point me in the right direction would be appreciated.
I know this is too late to help #amorio, but maybe it'll help someone else.
The error is specifically from ZShmStorage(), which means it's not apache or php's fault. It really doesn't help that the error message is a bit misleading.
A bit more context on the error, at least in my case. I'm betting it's the same using php(-cgi).
Starting php-fpm (/usr/local/zend/sbin/php-fpm --nodaemonize -c /usr/local/zend/etc/php-7.1-fpm.ini --pid /usr/local/zend/var/run/php-fpm.pid --fpm-config /usr/local/zend/etc/php-7.1-fpm.conf) [10.11.2020 18:18:05 ERROR] ZShmStorage(): Fatal error: failed to allocate semaphore. Permission denied
<br />
<b>Warning</b>: Could not initialize Zend Data Cache: Fatal error: failed to allocate semaphore. Permission denied in <b>Unknown</b> on line <b>0</b><br />
Zend Server installed to /usr/local/zend.
I ran into this same issue on ZendServer 9.1.10 on Ubuntu 16.04. In my case, I had to fix permissions on /usr/local/zend/tmp/datacache so www-data (apache user) had write access.
/usr/local/zend/etc/conf.d/datacache.ini is where the save path is defined.
When I start up all the redis-server of the redis cluster, all these servers continuously print logs like WSA_IO_PENDING clusterWriteDone
[9956] 03 Feb 18:17:25.044 # WSA_IO_PENDING writing to socket fd --------------------------------------------------------
[9956] 03 Feb 18:17:25.062 # clusterWriteDone written 2520 fd 15-------------------------------------------------------------
[9956] 03 Feb 18:17:25.545 # WSA_IO_PENDING writing to socket fd --------------------------------------------------------
[9956] 03 Feb 18:17:25.568 # WSA_IO_PENDING writing to socket fd -------------------------------------------------------- –
There is no way to specifically turn those "warnings" off in 3.2.x port of Redis for Windows as the logging statements use highest LL_WARNING level. This issue has been reported in my fork of that unmaintained MSOpenTech's repo (which I updated to Redis 4.0.2) and has been fixed by decreasing that level to LL_DEBUG. More details: https://github.com/tporadowski/redis/issues/14
This change will be included in the next release (4.0.2.3) or you can get the latest source code and build it for yourself.
Current releases can be found here: https://github.com/tporadowski/redis/releases
An issue was open in the official redis repo 10 months ago about that problem. Unfortunately it seems to be abandoned, and it hasn't been solved yet:
Redis cluster print "WSA_IO_PENDING writing to socket..." continuously, does it matter?
However, that issue may not be related to redis itself, but to the Windows Sockets API, as pointed out by Cy Rossignol in the comments. It's the winsock API that returns that status to the application, as seen in the documentation:
WSA_IO_PENDING (997)
Overlapped operations will complete later.
The application has
initiated an overlapped operation that cannot be completed
immediately. A completion indication will be given later when the
operation has been completed. Note that this error is returned by the
operating system, so the error number may change in future releases of
Windows.
Maybe it didn't get much attention because it's not a bug, although it's indeed an inconvenience that floods the system logs. In that case, you may not get help there.
Seems like there's no temporary fix. The Windows Redis fork is archived and I don't know if you could get any help there either.
Go on this location C:\Program Files\Redis
Open file redis.windows-service.conf in Notepad.
You will find a section like below:
# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)
# warning (only very important / critical messages are logged)
loglevel notice
# Specify the log file name. Also 'stdout' can be used to force
# Redis to log on the standard output.
logfile "Logs/redis_log.txt"
Here, you can change the value of loglevel as per your requirement. I think changing it to warning will solve this issue because it will log only essential errors.
My centos server is running web applications in LAMP stack. A couple of days back, the server was not responding for about 10 mins and I got http response failure alert from my monitoring tool. When I checked the httpd error log I found a huge log entry (~12000 lines) related to sendmail.
14585 sendmail: fatal: open /etc/postfix/main.cf: Permission denied
The server ran out of memory and not responding.
14534 [Fri Aug 19 22:14:52.597047 2016] [mpm_prefork:error] [pid 26641] (12)Cannot allocate memory: AH00159: fork: Unable to fork new process
14586 /usr/sbin/sendmail: error while loading shared libraries: /lib64/librt.so.1: cannot allocate version reference table: Cannot allocate memory
We are not using sendmail in any of our application. How can I stop this attack in future?
Thank you in advance!
Sorry I have no comment facilities; it looks like one of your website pages is vulnarable for code injection, finding out where and what page may be a huge job. Focus on input (forms) variables. Always sanitize input variables before using them! P.s. php uses "sendmail", even if you use Postfix, it will use a sendmail binary to send mail and the sendmail binary will redirect it to Postfix. If your forms work well and the 12k error log lines come out of the blue, then I would think someone is trying to inject code through your website (happens all the time by the way).
I have created a web application in Apache Cocoon.This website is running properly but after every 3-4 days, it stops responding. It doesn't run until and unless, we restart the tomcat service. In the catalina.2011-05-09.log file, it shows following error:-
"May 9, 2011 3:17:34 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/webresources] is still processing a request that has yet to finish. This is very likely to create a memory leak. You can control the time allowed for requests to finish by using the unloadDelay attribute of the standard Context implementation."
I am not been able to understand the cause of this problem. Can someone suggest me how to resolve this issue?
You are using a library that is starting one or more threads and is not properly shutting them down or releasing other resources captured by the thread. This often happens with things like Apache HTTP components (I get this error with Http Components) and anything that uses separate threads internally. What libraries are you using in your Cocoon application?
It is telling you the issue:
[...] is still processing a request that has yet to finish
You need to find out what that request is/is going to. One easy way is to have something like PsiProbe installed.
Also, it's not a bad idea to restart Tomcat every night. It can help alleviate these kinds of issues until you find the root cause.
Anyone using repcached?
Basically, I am experimenting with it in order to use it for storing sessions there, while providing failover with its buildin replication
Basically, I have 2 nodes running centos 5.4. The replication works fine wi\hen testing it and running some benchmarks with ab.
However, I am doing the below test.
I am having the 2 nodes started and replicating and start an ab test. While the benchmark is running, I take down one of the node, just to check the fail over.
At that point apache's error log starts printing
[Fri Oct 15 21:39:02 2010] [notice] child pid 2941 exit signal Segmentation fault (11)
It seems that some requests fail during the fail over
Anyone encountered such behavior?
Thanks
It turns out that this is caused by php's client memcache client.
Installing version 3.0.3 from pecl did the trick
The error appears with versions 3.0.4 and 3.0.5
I hope it will save people time