I made some changes to our sites httpd.conf file and possibly some other things in the past when I was tinkering with node.js and trying to set it up on our server.
Our server crashes every now and then and I haven't been able to figure out the problem, but I only just realised that it's probably being caused by something that I did while tinkering with node.js.
Here is a screenshot of our problem:
Any ideas why this is happening? I have tried resetting the httpd.conf file in the Apache directory using the /scripts/rebuildhttpdconf fix but it didn't seem to help.
After a chat with #Sneaksta and digging around in the error_log we found following error message:
[Thu Nov 08 12:22:24 2012] [emerg] (43)Identifier removed: couldn't grab the accept mutex
According to a blog post over at michaelwlucas.com this looks like an issue with apache's internal mutex. Putting the following line to your apache configuration should work around this issue (by simply using in-memory mutexes instead of lock files):
AcceptMutex posixsem
Related
I am trying to start a jBoss 5.1.0.GA instance and the output console is hanging on the [ProfileServiceBootstrap] Loading profile: ProfileKey#3f5f852e[domain=default, server=default, name=default] line.
The jBoss instance is copied from a remote server on which it works well.
There is not so much work logged (no more than 50 rows) and No error is displayed in console while starting up.
I understand that there may be some dependencies/connections/etc that it needs and are not satisfied, but I would expect an error to be thrown. Instead, it only hangs, without any other issue being reported.
I hope that this message will sound familiar to others that have worked more with older versions of jBoss and may direct me to investigate potential root causes.
Not proud of my findings... :) the issue was in fact that the logs were set not to write into the console. So, after looking for other log files, I found that the server started with the very well known statement Started in 1m:21s:836ms...
It is not really an issue nor an answer, but I leave this here in case others will find themselves in the same "I do not see the logs" situation (which should be also the title).
Note: in order logs to be shown, I have modified /server/default/conf/jboss-log4j.xml
For some reason, I'm getting a weird 403 issues when I use ZF2 + apigility + Cpanel. I do not know where to look!
I have the same code running on my local machine and an aws server. Both do not have the 403 issues when trying to authenticate using Oauth2.
But, once I moved my code to my client's machine that is running on Cpanel. I have been getting this 403 issue. Initially, I thought it might be a permission issue, but that is not it. The only thing that is different is probably server.
So, I'm guess the problem would be related to security settings.
Please advice what are the possible security settings that might be causing this problem...
If you have managed an error log, start by checking it in order to know exactly why you're getting that 403 issue.
I thought it might be a permission issue, but that is not it
This kind of issue could also be caused by a corrupted .htaccess file. Make sure the htaccess folder could be read.
Or may be you have to add RewriteCond to your main domain's rule :
RewriteCond %{HTTP_HOST} !^(www\.)?addon_domain\.com
where addon_domain should be replaced by the actual domain name.
But for better help, I think, you might do better to ask your host.
One of my Drupal websites homepage (just the homepage) is constantly redirecting when the site is visited. Tends to happen randomly. Which I don't understand why it would do this. I talked a bit on the Drupal community and it is said to be a server issue. Not Drupal.
Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.
I don't currently have CPanel access to check the server logs though. I am somewhat fluent in terminal and I have root SSH access to the server.
Where and what commands would I have to run to find and access the logs that could possible help me figure where to start with fixing this? Would they just be located in /var/? What would I be looking for once I get access to the logs, just a steady stream of the duplicated IP address that it keeps being redirected too?
Found out this IS a Drupal Commerce Kickstart core issue.
Found follow errors in php logs:
PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini
PHP Fatal error: Unsupported operand types in public_html/dev/profiles/commerce_kickstart/modules/contrib/search_api_db/service.inc on line 970
Got the redirect loop to stop after increasing the max_input_vars to 9000. I feel it's more of a bandaid fix though. So I'm taking this further into the Commerice Kickstart community.
I wrote a quick PHP page to handle 502 requests. Nginx will re-direct to this page when a 502 is encountered and an email is fired off.
The problem is, most of the time that the 502 is encountered is because PHP has died, so writing to the DB and sending an email using PHP is no longer possible. Tweaks to PHP-FPM settings have done a lot to help (restarting PHP, etc), but I'd still like a fall-back.
There are numerous ways to send an email outside of PHP, but I am curious what others out there are doing with good success? I'd like to keep it simple for configuration (i.e. not have yet another complex dependency to worry about on the servers) and reliability reasons.
Googling and searching SO didn't turn up much, probably because "dies" and "fail" bring back a lot of false positives for my scenario.
What about use a cronjob (bash based) to parse error_log file periodically (x hours) and send an email (mutt/mail) when find something like resuming normal operations in the last period (x hours). I think is simple and effective...
[Thu Dec 27 14:37:52 2012] [notice] caught SIGTERM, shutting down
[Thu Dec 27 14:37:53 2012] [notice] Apache/2.2.22 (Ubuntu) PHP/5.4.6-2~precise+1 configured -- resuming normal operations
UPDATE:
#Brian As #takeshin says cronjobs can run even every second if you want, but some sysadmins could bite you... :|
Here is what I've ended up doing. I've not rolled it out to our prod servers yet, but all testing thus far looks good.
Nginx does not support CGI natively, so you need another means to do it. thttpd fit the bill nicely. There is a good write up the nginx wiki showing how to use it.
I configured thttpd with the following:
dir=/var/www/htdocs
user=thttpd
logfile=/var/log/thttpd.log
pidfile=/var/run/thttpd.pid
port=8000
cgipat=**.cgi
And added this to my nginx config:
error_page 502 #thttpd;
location #thttpd {
include proxy.include;
proxy_pass http://127.0.0.1:8000;
}
Finally, I created a basic CGI script that calls PHP on the command line and passed in my already-written PHP script. This was an ideal solution for me because the script was already set up to log to our alerts table and fire off an email. This is also real-time, as the script will execute as soon as nginx returns a 502 code (subsequent 502s will not hammer me with emails, per the logic of the script).
I was able to run some simulation tests be forcing nginx to return a 502 (see more here).
I'm going to continue tweaking this, but I'm pretty happy with the relative ease of deploying it and that I could re-use existing code.
We have dual solution.
We use shell script to send out email notifications, if PHP dies. We check if php service is running with shell command in the shell script, if it is not running, we'll fire off a shell command to send an email.
This is all in a few lines of Shell Script. Not too hard.
Of course, set it up in cron.
I've moved a WebBBS board from one server to another. Ever since the board doesn't work.
I'm getting an Apache error whenever I try to access the board. Don't even know where to start the debugging, I'm not a Perl person. The file paths remained the same and there isn't any DB involved.
http://gammonline.com/members/board/
Any ideas?
After a bit of testing I believe that the problem has something to do with the index.cgi which is located in that folder (not getting the error when renaming it).
Thanks,
Roy.
More information about this error may be available in the server error log.
Says it all. You will have to find the error log and look at it.
If you are using CGI, the first step is to check you have given it the right permissions so it is an executable script at all.
chmod 755 index.cgi
This is caused by Apache config errors. Set LogLevel debug and tail -f the error log. It will probably be something to do with .htaccess permission for override, or, it's requiring a module which isn't loaded. The error log will tell you instantly.