Simplepie plugin causing an internal server error? - simplepie

My website host did some checking for me and indicated that Simplepie plugin is causing a memory problem. Can you say which files need to be removed in order to access my Sopacameraclub.com site again? below is the info provided to me:
[3:23:25 AM]Vyshnavi Gottumukkala:From the error logs I see 20180118T164756: www.sopacameraclub.com/wp-admin/index.php
PHP Fatal error: Out of memory (allocated 118489088) (tried to allocate 1966080 bytes) in /hermes/bosnaweb08a/b2428/ipg.sopacameraclubcom/wp-includes/SimplePie/Item.php on line 2736
[3:25:03 AM]Vyshnavi Gottumukkala:From the error, I see issue with SimplePie application . Please contact the vendor and correct it or you can remove the files from your website

Simplepie was not causing the problem. I had too many plugins loaded which was causing the memory problem. Once I deactivated enough plugins there was enough memory to keep my site running.

Related

ZShmStorage(): Fatal error: failed to allocate semaphore. Permission denied

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.

RabbitMQ_MQTT failing to start

I am trying to enable mqtt in rabbitmq. Plugin has been enabled successfully but when I make the changes in the config for rabbitmq_mqtt, it fails to start the service. Even after googling a lot, I am not able to see the same issue being raised.
RabbitMQ_MQTT is failing to load even when the port is available.
Starting broker...
BOOT FAILED
===========
Error description:
{could_not_start,rabbitmq_mqtt,
{{function_clause,
[{rabbit_networking,tcp_listener_addresses,
[{1993}],
[{file,"src/rabbit_networking.erl"},{line,176}]},
{rabbit_mqtt_sup,'-listener_specs/3-lc$^0/1-0-',3,
[{file,"src/rabbit_mqtt_sup.erl"},{line,55}]},
{rabbit_mqtt_sup,init,1,
[{file,"src/rabbit_mqtt_sup.erl"},{line,47}]},
{supervisor2,init,1,[{file,"src/supervisor2.erl"},{line,305}]},
{gen_server,init_it,2,[{file,"gen_server.erl"},{line,365}]},
{gen_server,init_it,6,[{file,"gen_server.erl"},{line,333}]},
{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]},
{rabbit_mqtt,start,[normal,[]]}}}
Log files (may contain more information):
/var/log/rabbitmq/rabbit.log
/var/log/rabbitmq/rabbit-sasl.log
{"init terminating in do_boot",{could_not_start,rabbitmq_mqtt,{{function_clause,[{rabbit_networking,tcp_listener_addresses,[{1993}],[{file,"src/rabbit_networking.erl"},{line,176}]},{rabbit_mqtt_sup,'-listener_specs/3-lc$^0/1-0-',3,[{file,"src/rabbit_mqtt_sup.erl"},{line,55}]},{rabbit_mqtt_sup,init,1,[{file,"src/rabbit_mqtt_sup.erl"},{line,47}]},{supervisor2,init,1,[{file,"src/supervisor2.erl"},{line,305}]},{gen_server,init_it,2,[{file,"gen_server.erl"},{line,365}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,333}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]},{rabbit_mqtt,start,[normal,[]]}}}}
You need to check the log in /var/log/rabbitmq/startup_log or /var/log/rabbitmq/startup_err. It is very possible that your changes for the config file is causing the problem. Usually, it's the syntax of the config file causing the problem. If you are using the classic format, it's array like syntax, having extra comma or missing comma could also prevent you from starting the service.

Mediawiki error empty response

I install Mediawiki in my server following Tutorial, but sometimes ERR_EMPTY_RESPONSE apper as error, without any apache error log message.
My Mediawiki version is 1.29.1
The Zend heap corrupted error can be solved in a few ways... in your case the most likely fix is to increase the value of output_buffering in your php.ini file.
Most other causes of this are at "the developer level", which if you are using Mediawiki is unlikely to be the problem.

Tomcat showing this error "This is very likely to create a memory leak". How to resolve this issue?

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.

Apache is leaking semaphores when running mod_mono

I'm running an ASP.NET MVC2 application under mod_mono with mono 2.8.1 and currently have to periodically clear out semaphore arrays that apache seems to be leaking.
I started with mono rpm's for 2.6.7 a while back but had had some issues both with leaking semaphore arrays (i.e. more and more accumulating in ipcs) and some incompatibility with ASP.NET MVC2, so I built 2.8 from source. The leak continued, so I just built 2.8.1 from source and the same thing is still happening. This is on an Amazon AMI (i guess it's centos under the hood). The symptoms are that semaphore arrays keep building up and if i don't manually remove them with ipcrm after a while requests to ASP.NET pages return no content with no errors in the logs. I've also reproduced the same issue in an centos 5.4 AMI.
Is anyone successfully running ASP.NET under apache/mod_mono and I'm just running into some edge case? Since I can't find any mentions of this happening to anyone else, I assume it's not general ASP.NET bug. Any ideas how i can troubleshoot this further?
Finally figured this out and while the solution exposes my own mistake of not following up other warning I was receiving, i figure this should be useful to anyone else runnning into this.
By default apache config has the below config order:
Include conf.d/*.conf
User apache
Group apache
I.e. all conf files (usually where vhosts are defined) are loaded before httpd user and group are set. This results in the below warning on restart:
[Mon Jan 24 00:12:50 2011] [crit] The unix daemon module not initialized yet.
Please make sure that your mod_mono module is loaded after the User/Group
directives have been parsed. Not initializing the dashboard.
While everything seems to work anyhow, this is the cause for the semaphore leak. If you move the Include after the User/Group, the warning goes away and mod_mono no longer leaks semaphores.
I've seen this with the shared memory used by cross-process handles.
My fix was to set MONO_DISABLE_SHM=1, however I'm not sure if this is your problem since the cross-process handle support is disabled starting with 2.8.
You could probably still try MONO_DISABLE_SHM to see if it makes a difference.
Try to use new sgen garbage collector instead of Boehm.
To use the new garbage collector, you
just need to invoke Mono with the
--gc=sgen command line option, or set the MONO_ENV_OPTIONS environment
variable to contain "--gc=sgen"
option. By default Mono continues to
use the Boehm collector.