I am testing an auth module with apache 2.2 server on 6.1 power AIX, 64 bit platform. The apache server doesn't start at all when I give my module path name in httpd.conf, it works fine on AIX 5.3 though with same module.
No crash, no other error message than following in error in error_log file:
httpd: Syntax error on line 423 of /home/apache22-aix64/installApache/conf/httpd.conf: Syntax error on line 9 of /
/home/apache22-aix64/installApache/conf/agent.conf: Cannot load /home/agent/apache/lib/auth-module.so into server: Not enough space
I have checked by increasing ThreadStackSize to 6mb, increased memory and other parameters, but issue is still the same. Issue is common in prefork n worker mode of apache server.
That's a new one on me... I'm guessing you are out of something (yea, brilliant guess right? ). Try checking ulimit -a between the two systems (5.3 and 6.1). I presume you are starting apache using the same type of id (non-root id with the same limits, permissions, etc).
I would also suggest tagging this with Apache to see if some apache guys might be able to help out. We need to determine what is it out of -- memory, stack, disk space, paging space, etc.
Did you build this apache version yourself?
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.
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've been having a problem with my (development) site hanging when I try to login using LDAP credentials. Using xdebug, I was able to pinpoint the hang to a specific line of code, which is a call to ldap_bind(...). After days of trying to understand why it is hanging, one of my debugging techniques was to disable mod_ldap, and then just try to get any error to show up in apache log (after this has started, apache error logs haven't been recording any errors while performing this http request; It 'hangs' too).
What I did
I disabled the module (sudo a2dismod mod_ldap), restarted the server (sudo service apache2 restart), and confirmed that the module isn't enabled (apache2ctl -M does not show mod_ldap)
The Problem
It still hangs when it reaches ldap_bind(), however, it shouldn't even be reaching that point because without mod_ldap, my code shouldn't even be successfully calling ldap_connect() (right?) which is returning (resource) resource id='5' type='ldap link' (meaning the call was successful). I'm expecting a NoMethod or Function error.
Why can php make a call to a module that isn't enabled, and how do I stop that behavior?
Version
Ubuntu 14.04
Apache 2.4.7
PHP 5.5.9-1ubuntu4.5
Well it turns out, I had a novice understanding of what was happening. Never occurred to me that ldap_connect() as a php call had nothing to do with mod_ldap or any apache module. Thus, disabling/enabling apache mods wasn't doing anything because... it had nothing to do with apache mods.
So... I was able to disable ldap php extension with
sudo php5dismod ldap
and able to check that it was disabled with
php -m
And sure enough, after restarting the server, running my script caused a No function error for ldap_connect() (just as I was expecting/hoping). Now I just need to figure out why ldap_bind() hangs...
I am aware that this question is asked many times in forums and I have tried all solutions mentioned in them, but no luck.
Actually, I doubt when last time I was trying to replace the /etc/sysconfig/iptables with my own iptables rules, I mistakenly replaced /etc/init.d/iptables and restarted the machine. And as expected it didn't start. Then I detached the EBS from this instance and attached to a new RHEL instance and fix the mess up by copying back the /etc/init.d/iptables from backup (I used to take backups before replacement :) ) and same for /etc/sysconfig/iptables.
I have also put some custom startup scripts in /etc/init.d folder for our application to start on instance reboot. I have removed those too to make sure any of my script is not causing this. But still system is not allowing me to connect via ssh. AWS console is showing 2/2 checks being successful, but not able to connect via 22.
Here is the last few lines of system log which states that something wrong is happening after or on iptables startup but not showing what. :(
blkfront: xvde1: barriers disabled
Changing capacity of (202, 65) to 62914560 sectors
xvde1: detected capacity change from 0 to 32212254720
EXT4-fs (xvde1): mounted filesystem with ordered data mode. Opts:
dracut: Mounted root filesystem /dev/xvde1
dracut: Loading SELinux policy
type=1404 audit(1398404320.826:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
type=1403 audit(1398404321.795:3): policy loaded auid=4294967295 ses=4294967295
dracut:
dracut: Switching root
udev: starting version 147
Initialising Xen virtual ethernet driver.
microcode: CPU0 sig=0x306e4, pf=0x1, revision=0x415
platform microcode: firmware: requesting intel-ucode/06-3e-04
Microcode Update Driver: v2.00 <tigran#aivazian.fsnet.co.uk>, Peter Oruba
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
ip6_tables: (C) 2000-2006 Netfilter Core Team
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
ip_tables: (C) 2000-2006 Netfilter Core Team
Can anyone help me in identifying what is going wrong here?
Got it fixed.
Actually, it was not the problem of iptables. Again it was due to the known bug in RHEL 6.4 on EC2 which puts wrong entries in sshd_config files. Although, I have checked this file for wrong entries in my first attempt to resolve the issue, somehow it was being created again, may be because every time I start a new machine using my AMI or new RHEL 6.4 AMI. In both cases, AMI is still registered as 6.4, though the OS on the disk is updated to 6.5. May be this was the reason that it was creating wrong entries in sshd_config. Now, again I have fixed this file for wrong entries and created new AMI using RHEL 6.5 and attached the EBS volume from instance created using my RHEL 6.4 AMI, it works fine.
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.