3

I have a CentOS 6.5 VM set up using Apache HTTPD 2.2 as the web server and I'm using GulpJS for my build process. When I update a CSS file the GulpJS build process runs ok and if I look at the file on the VM I can see the updates, however when served via Apache HTTPD the file doesn't have the changes in it. If I edit the file using vi, make no changes and simply save it again Apache HTTPD then picks up the changes and outputs the correct file.

I have disabled the mod_cache module (e.g. commented out the LoadModule directive for it) as I thought that might be the cause but that has made no difference.

Has anyone else come across this issue and know how to fix it?

[UPDATE] - Just been looking at the httpd access log and I can see that the file is being served by httpd everytime, before and after updates but nothing changes:

192.168.56.1 - - [22/Jun/2014:09:27:42 +0100] "GET /includes/min/stylesheet.min.css HTTP/1.1" 200 135882 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36"
192.168.56.1 - - [22/Jun/2014:09:29:22 +0100] "GET /includes/min/stylesheet.min.css HTTP/1.1" 200 135878 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36"

Apart from the file length. This would suggest that httpd is seeing the file update but it is not updating in the browser. I have tried several different browsers, clearing browser caches, etc.. but until I edit the file on the server using vi and save it again no browser will load the new version of the file, which brings me back to thinking httpd is still serving the wrong version of the file. So odd.

[UPDATE 2] - I believe this might be something to do with VirtualBox and the shared folders. The files for the site are on the host (Mac OS X 10.9.3) and compiled there using NodeJS. They are compiled into a folder that is shared with the guest OS (CentOS) using VBox's shared folders. If I look at the file in the directory via the console I see:

-rwxrwxrwx. 1 root root 135881 Jun 23  2014 stylesheet.min.css

As you can see, instead of the normal Month, Day and Time for the file, it has Month, Day and Year instead. This looks out of place to me, but I have no idea what this means or if it is significant.

andrewdixon
  • 228
  • 3
  • 10
  • After disabling `mod_cache`, have you purged the cache (`htcacheclean`)? – dawud Jun 22 '14 at 09:16
  • Thanks for the suggestion dawud however htcacheclean doesn't make any difference. I don't think the cache was actually doing anything anyway, it is a standard install of httpd and I never configured mod_cache to do anything, it was simply just loading the modules, mod_cache and mod_disk_cache, but there was no actual configuration for them. – andrewdixon Jun 22 '14 at 09:54
  • The fact that you can see the updated file by **saving** it, even without changing the content, _but_ updating the "access", "modify" and "change" timestamps as seen by `stat(1)`, makes me think it is indeed a caching problem. – dawud Jun 22 '14 at 10:00
  • Can you retrieve the updated file using a CLI tool, like `wget` or `curl`? – dawud Jun 22 '14 at 10:03
  • Did you clear the cache of your browser each time? If your server provides explicit (long enough) expiration dates for content, it is quite possible that your browser simply uses its cached content rather than sending a request to the server. – didierc Jun 22 '14 at 14:27
  • Retrieving the using curl makes no difference, it still shows the old version until I load and save the file using vi. Even restarting httpd doesn't make any difference. I checked for updates and updated to the latest httpd and kernel, but this didn't help either. – andrewdixon Jun 23 '14 at 17:59

1 Answers1

3

Found the solution to this. It was an Apache HTTPD cache issue. I put the mod_cache and mod_disk_cache modules back in and then set the following directive:

CacheDisable /

This has solved the problem. Not sure why simply not loading the cache modules didn't have the same effect.

UPDATE: While this did appear to solve the problem for some time it doesn't appear to be the actual solution. The problem actually turns out to be to do with the machine running on VirtualBox and the files it is serving being on the host machine and mounted to the guest via using vboxsf. The problem and solution is explained in the following blog post:

http://www.frandieguez.com/blog/2013/05/solving-caching-issues-with-vagrant-on-vboxsf/

andrewdixon
  • 228
  • 3
  • 10