In top I keep seeing zombie processes (not more than one at a time), they disappear quickly (within 10 seconds), but a new zombie pops up a few seconds later. My server runs 3 sites, 2 written in PHP, one in Perl, all served by Apache . For the PHP sites I use mod_rewrite to create nice looking URLs. I having been trying to figure out which page or script causes these zombies, but can't find it. Is there a way to connect the PID of a process to the request it was executing?
To find out what causes the zombies I stopped the Perl site and one of the PHP sites, nothing changed, the zombies keep coming, so my best guess is that I have narrowed it down to one site, but then again, maybe it has nothing to do with a particular site I (I can't take the remaining site offline to check, since people are working with it).
I am running Debian on that server, this is the config:
Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 PHP/5.2.6-1+lenny8 with Suhosin-Patch
mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0
Any help or pointing me in the right direction is greatly appreciated, I have been googling and trying things for days now (I learned a lot from it though ;-) ).
During the quiet Christmas holidays I had the opportunity to take the 3rd site offline for a couple of minutes. To my surprise I kept seeing zombies popping up, so it seems it has nothing to do with one site in particular but rather with some setting in Apache. Any ideas anyone?
I just answered a very similar question
Apache spawning zombie processes when php is called
the short answer is it's normal.
By enabling mod_status you'lle get some more details in the /status url of your server, and even the details of the last page served if you set the ExtendedStatus directive to "On". But you should not use that setting for a to long time in a production server.
Then I would like to know how do you know it's a zombie process? Are you sure it's not the 'normal' subprocess of apache, serving the client requests? How many subprocess do you have for your apache?
Related
I could ping my websites but I got a 404 going there.
My server was running normally, no new mail for root.
Is there a service to alert you when your websites are down ?
What do you usually do to understand why it's down?
I took a look at the apache2/error.log and saw that it couldn't access one of the website I had deleted a few hours ago. I just did a a2dissite and restarted and it was fixed, I could access my websites.
I either got lucky or I postponed a problem. Any idea what I should do next to make sure everything is alright? (I'm on debian by the way)
I'm running XAMPP on my windows machine and experiencing a problem with Apache crashing a couple times a day. When it does, a dialog pops up and I have to manually tell windows to end the program. After I do that, XAMPP automatically starts it back up in a couple of seconds with no issues. When it crashes while I'm not home though, the server is down until I get back. So I have two questions:
Are periodic crashes something that should be expected, or is this indicative of another issue I should be trying to pinpoint?
If this is something I should just learn to deal with, is there a way to automatically restart httpd.exe when these issues occur, so I don't experience down time when I'm away from home?
You'd look into log files, especially the Apache access and error logs, to see what happened, when you are not at home. I've met some similar situation: I have a problematic PHP script hosted on my server, when someone visits the page, it leads to an Apache crash.
I'd suggest you do the investigation as follows:
Search the timestamp of recent Apache restart.
Check the Apache access log to see whether there are some scripts have been accessed.
Manually access these scripts in your browser (to see if Apache will crash again)
You'd better check the PHP error log as well.
If there is really nothing suspicious, you can try WAMP bundle alternatively, which is also a very popular PHP development environment and it is stable.
Although there aren't many cases in which one should "expect" periodic crashes, in this case you are better of reconsidering your setup. From the frontpage of the XAMPP site:
XAMPP is the most popular PHP development environment
Sure, you can use it as "production" server, but XAMPP isn't build for hosting websites, it is intended as development server, so you don't have to manually setup Apache, PHP and MySQL on you dev machine. If you actually want to run your website for the public, setup Apache/IIS, MySQL and PHP manually, those products on there own are made for running in production. Or you can consider getting some cheap shared hosting somewhere, so you don't need to setup anything.
HTTP requests of resources randomly - about between 1-5% of the time (per resource, not per page loads) - take extremely long to be delivered to the browser (~20 seconds), not uncommonly hanging indefinitely even. (Server details listed in list at the bottom).
This results in about every 5th request to any page appear to hang due to a JavaScript resource hanging within the <head> tag.
The resources are css, js and small image files, served directly by apache (no scripting language), although page loads (involving PHP or Rails) also rarely hang, with equal chances as any other resource (1-5% of the time), so this seems to be an Apache Request related issue.
Additional information:
I've checked the idle workers on server-status and as expected, I still have 98% of my idle workers. Although this may be relevant as the hangings apply to static resources not served by FastCGI (the resources are static).
I am not the only one with this problem. Someone else is also having the same problem, and from a different IP address.
This happens in both Google Chrome and Firefox as HTTP clients.
I have tried constantly force refreshing the same JS file in a new tab. It eventually led to the same kind of hanging.
The Timing tab for Google Chrome reports 34ms waiting and 19.27s receiving for one of these hanging requests. Would that mean Apache already had the file contents to be delivered ready, only had trouble delivering it in a sensible amount of time?
error.log doesn't show any errors. There are some expected 404 and 500 errors in error.log, but those aren't related to the hanging; those are actual errors for nonexisting pages and PHP fatal errors.
I get some suspicious 206 Partial Content responses mostly for static content, although the hanging happens more often then those partial contents. I mostly get 200 OK responses everywhere and I can confirm indefinitely hanging resources that were reported as 200 OK in the apache access.log.
I do have mod_passenger installed for Redmine. I don't know if that helps, but suspiciously this server has it installed unlike all the other servers I worked with. Although mod_passenger shouldn't affect static content, especially not within a non-ruby project folder, should it?
The server is using Apache 2.4 Event MPM on Ubuntu 13.10, hosted on Digital Ocean.
What may be causing these hangings and how could I fix this?
I had the same problem, so after reading this thread I tried setting KeepAlive Off in my apache config which seems to have helped- all resources have expected waiting times now.
Not a great "fix", but at least I am one step closer to figuring out the cause and pages aren't taking 15s to fully load in the mean time.
I'm hosting my website www.xgclan.com with the latest apache 2.4.1 and sometimes my server gets jammed, it doesn't seem to send any data but you don't get a timeout like when the Apache process isn't running.
A reboot of the process resolves this issue.
It seems to happen when you open the website in multiple browsers on the same system.
I've tested it on 2 different systems to make sure its not a bandwith or cpu problem.
Putting this without the quotes "AcceptFilter http none" in the httpd.conf fixed the issue for me.
I found the solution here: http://www.apachelounge.com/viewtopic.php?t=4543&postdays=0&postorder=asc&start=20
I've been developing an application in CakePHP recently, and all was well until it wasn't. On our development server (which I control) the application runs just fine. On the live server (which our university controls) most of my POST requests result in a 403 page. I've figured out that PHP is never even being called in these cases, and I'm 99% certain that the only real configuration difference between the two is mod_security2.
Here's my trouble. I cannot see the error_log file, because I am not root. I can't even list the directory that it's in. We have got to have the slowest admin on the planet, and I'm trying to get past this issue as quickly as possible. Is there any way to debug mod_security2 without simply throwing bits of post data at it until it breaks hoping to "guess" at what you might be doing wrong?
I've tried looking through the configuration files (which I do have read access to) but I've never used this mod before, and it's like wading through molasses. I don't even know where to begin.
Disabling the mod outright isn't an option, I'm simply going to have to work with it I'm afraid. HELP.