I was trying to get the Apache server to work. When I was done with it I uninstalled the service and deleted all the server files. However I noticed even after all that going to localhost address shows me this page
How do I go on about removing this page from my localhost? Thanks
To expand on the previous comment ... after killing all httpd processes (and this may be a problem because Apache will respawn children) ... then reboot the system to see if the problem persists.
If it does persist, then Apache has not been uninstalled and it'll have to be uninstalled. If the system uses sysvinit, look in /etc/init.d for a script that starts Apache and disable that script.
If the problem does not persist then Apache was properly uninstalled and the problem will not recur.
Related
I have setup a Vagrant box with Ubuntu 12.04 and Apache2 (all very vanilla, as per Vagrant's tutorial). I've been testing it for web development and I stumbled across a weird issue (not sure if bug or feature):
I have setup a synced folder across my machine and the VM folder. Apache has been serving the files mostly well, except (up to now) for a JSON file I'm using.
If I edit it locally, it seemingly syncs it to the VM folder. Both copies are the same.
Although, if I XHR it from the browser after modifying it, I still get the previously served version of that file.
At first, I thought the browser had it cached, but after trying with 2 different browsers (Chrome(ium) and Firefox), after clearing their respective cache, the issue remained.
I finally managed to go around it by reloading (vagrant reload) the VM.
What I was wondering is if this is a bug or a feature and how can I go around it. Is Apache configurable to not cache server side for a specific folder/file/filetype?
vagrant use previous setting until you provision that new setting again, so after every change in vagrant do provision to see reflected output. There is no apache2 cache problem.
For that use command
vagrant reload vmname --provision
if your vm name is default then use
vagrant reload default --provision
it will reboot vagrant vm and apply change to vm .After provision you will be able to see changes.
Finally figured it out. This relates to an issue that occurs with both Apache and /or Nginx: the sendfile option in server configuration.
Basically a new file wasn't being sent/updated client side even when it was changed server-side by Vagrant sync mechanism.
Check this answer for a solution: here.
For some reason Apache just doesn't seem to want to work. I have been trying so many things to try and fix it but with no luck. At first there was programs blocking port 80. A few of the programs I tried to stop on port 80 are skype, World Wide Web Publishing Service, IIS(Internet Information Services), and NT Kernal & System. Then I ran Apache in the cmd. I typed: cd:/apache/bin then I typed httpd.exe but nothing happened and the cursor just kept blinking on the next line. I also went to ApacheMonitor in the bin file and ran that, then went to the little icon on the bottom and clicked start but it just said The requested operation has failed! I don't know what to do now.
I have windows 7.
I would recommend to Install Apache as a service.
However, if you want to start Apache via command prompt. First thing you check if the syntax in your conf files is ok. Open a command prompt as an Administrator. Change to Apache bin directory and use below command.
httpd -t
If it returns Syntax OK, that's a good news. Errors will be displayed if any. Fix all errors.
Once syntax looks ok, run below command to start Apache.
httpd -k start
It should start your Apache. If it doesn't check /logs/error.log and see what's going on.
Good Luck!
Sometimes, for no real reason I get the following console message and a completely blank screen after deploying code to the server:
net::ERR_INCOMPLETE_CHUNKED_ENCODING
An Apache restart fixes it but I can't see why it happens. The file system changes but not any config. I've never encountered it when not doing a deployment, so something about the file system changing whilst apache is running seems to cause it.
The document root is a symlink (current/) to the latest release folder.
This might not be your problem, but it solved it for me so i'm going to throw it out there anyway - setting opcache.fast_shutdown=0 fixed it. It is disabled by default according to the php docs
but had been enabled in our setup.
I had this problem with phpmyadmin. Try disabling your antivirus.
I want to test some code on localhost before uploading to a live site. So I decided to install Apache. I'm running 64bit windows 7 enterprise edition. I downloaded httpd-2.0.64-win32-x86-no_ssl.msi. I installed it under C:\Program Files (x86)\Apache Group\Apache2
I have set domain name and server name to localhost in my installation, and used default value for all other steps. In my configuration file httpd.conf, I have ServerName localhost:80.
I followed everything I can find on online apache installation tutorials. But when I typed in localhost in my browser, I got a 404 error :(
I know it's very hard to diagnose this way, but I just wonder if someone can spot an important step I'm missing.
I'm feeling it could be something to do with my 64bit machine, and the long folder name Program Files (x86). But I have tried to install on C:\Apache directly and failed too (even got an error during installation). Can someone help?
Finally figured it out. Apache service didn't start because another system process was listening to port 80. Refer to these two posts for solutions:
http://forums.zpanelcp.com/archive/index.php/t-5265.html
http://www.softaculous.com/board/index.php?tid=1575&title=Apache_won%27t_start
Good luck to all!
Did you start the service?
Also, you should install XAMPP or WAMPP, which offers Apache, PHP and MySQL support without all the configuration hassle.
If you got a 404 error then either the webserver is running or you failed to start it and have something very wrong with the existing network config on your machine.
The latter is a lot more likely - and you can check this by looking at the logs which it has generated - there should be entries in both the access and error log.
If the problem is the spaces in the path (you'll see an error relating to the documentroot from the entries added to the error_log at startup) then (IIRC) you can either enclose the path in double quotes or use a path for the document root which doesn't have spaces - the content doesn't have to site below the directory you installed Apache into - indeed it's arguable that using a different path is good practice. Note that several versions of mod_fcgid don't like paths with spaces even if you quote them.
I have apache pointing to a symbolic link for a website. I'm using capistrano to deploy the code so it updates the symbolic link to point to the new release
After capistrano updates the symbolic link to the new release directory apache uses the previous release directory.
The weird thing is it doesn't happen all the time. After a deploy everything either works fine or apache follows the previous link until i restart or reload apache.
any ideas?
This may depend on Apache httpd holding a handle on the old symlink. As long as that is the case the old data (symlink) is not thrown away in Unix based filesystems.
It seems you are unable to predict whether this is the case. Maybe use of lsof can help. What could also help is to trigger a graceful restart of httpd.