I recently installed APC on my production server but It's not working as expected.
All my projects are handled with SVN, and on production release I have a post commit hook that runs a svn export to the correct directory.
The problem is that with APC, my website fails to display anything(white page) unless I restart apache.
I check and apc.stat is On so I dont know what is happening !
Try to change this configuration setting:
apc.stat_ctime = 1
From php.net:
Verification with ctime will avoid problems caused by programs such as svn or rsync by making sure inodes haven't changed since the last stat. APC will normally only check mtime.
Related
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.
I am using Apache httpd on localhost to connect to the project I'm working on, I have been deleting web cache when website is showing the old project instead of the new one. However recently the project is stuck on an outdated version and restarting/clearing cookies won't work with the user I'm assigned.
I tried using another user with my project and it works just fine. I recently did use svn revert which may have caused my user to get stuck with old project, but I'm not sure that's the problem.
Commands I use to start and stop:
sudo service httpd start
sudo service httpd stop
Any advice or tips are greatly appreciated.
Update: I managed to get the page to update the html, however my JavaScript won't load which I suspect is due to another user being stored and thus not accessing the database I use which leads to nothing being generated.
(Posted on behalf of the OP).
I got everything to "work" again by accident, I made some edits to PHP and my PHP crashed because of a syntax error. When I fixed it back to original stage it was working again. It most likely is related to a user the previous owner created that caused the problem.
Just clear Temporary files
In windows CTRL+R and type %temp% and delete all the files it will help to you
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.
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.
Recently I have been plagued by an error on committing to a single SVN repo using TortoiseSVN (1.8.7.25475) or AnkhSVN (2.5.12471.17):
Error running context: The server sent an improper HTTP response
Here is a screenshot of the error in TortoiseSVN:
The pixels differ of course, but the error is the same in AnkhSVN.
This only seems to affect attempts to commit modifications, not additions or deletions; and I can commit mods to several other SVN repos on the same server just fine.
Since my teammates continue to commit mods to the repo in question and the issue has only struck my commits to that repo, I tried committing simple mods after a fresh checkout of the repo: a few one-mod-at-a-time commits worked, but then...same error.
I also searched for, reviewed, and tried some possible solutions (e.g. in a thread on the TortoiseSVN forums to which Stefan Küng replied) - a registry tweak (deleting HKEY_CURRENT_USER\Software\Tigris.org - after exporting it for backup of course), checking my global properties, and ensuring that I am not using a proxy. Same error.
Finally, I tried both repairing and downgrading TortoiseSVN. Same error.
Has anyone else encountered this error under similar circumstances and found a solution to it?
Note that some related search results mention tweaking httpd.conf or other aspects of the SVN server, but server tweaks seem inappropriate to me. Again, my teammates continue to commit mods to the same repo using the same version of TortoiseSVN, the same OS (Win 7 Pro 64-bit) etcetera. Maybe I have missed something on the server that could just happen to affect me, though.
Upgrade your Subversion client to the latest version.
Outdated answer:
ON THE CLIENT MACHINE! Open %APPDATA%\Subversion\servers in a text editor and add the line http-bulk-updates = yes, save the file and see if it helps.
If it helps, you'd better configure Apache HTTP Server's httpd.conf with SVNAllowBulkUpdates prefer directive so that all Subversion 1.8 clients could connect without any errors.
If there are more than just you who get this error in your organization and adjusting server's configuration is still unacceptable, you can change the setting http-bulk-updates = yes via Windows Registry so adjusting this on all affected machines can be done via AD Group Policy.
Read more info in Apache Subversion 1.8 Release Notes.
P.S.: faulty network hardware / firewall / antivirus is still the root cause here. The above is just a workaround to revert to the behavior of Subversion 1.7 and older client with neon network library. BTW, I guess that the installed antivirus is NOD32 or BitDefender.
In my case it was problem with nginx's gzip (I run SVNEdge SVN server behind Nginx).
I disabled gzip and everything started working.