I am attempting to clear the nginx cache when the CMS (ExpressionEngine) publishes new content. I have been just purging the entire folder and letting the cache rebuild itself. It seems to be working fine, but it is filling up the error logs with these entries:
2014/12/15 12:35:09 [crit] 21686#0: unlink() "/var/nginx/cache/default/6197dda0a6cadcec5563533cb6027580" failed (2: No such file or directory)
2014/12/15 12:35:10 [crit] 21686#0: unlink() "/var/nginx/cache/default/bb8eca6b51c655989bd717a9708b244e" failed (2: No such file or directory)
2014/12/15 12:35:10 [crit] 21686#0: unlink() "/var/nginx/cache/default/6f9b9aea38c5761a87cffd365e51e7a4" failed (2: No such file or directory)
It seems that nginx keeps track of the cache files and gets confused when it goes to purge them after I already did.
Is there a better way to be purging the cache that doesn't cause these errors?
Off the top of my head, a way of doing this is specifying secret headers in nginx which will bypass cache, thus theoretically purging the existing files.
But also, there is nothing wrong in your way of doing it. The only ugliness is these logs, which invariably show up as [crit], which they are not in case of manual purge. :)
"It appears that these errors occur when NGINX itself tries to delete cache entries after the time specified by the inactive parameter of the fastcgi_cache_path directive. The default for this is only 10 minutes, but you can set it to whatever value you want. I’ve set it to 7 days myself, which seems to work well as I haven’t seen this error at all after changing it."
Source: https://www.miklix.com/nginx/deleting-nginx-cache-puts-critical-unlink-errors-in-error-log/
Related
I have the error "Mage registry key "_singleton/my_observer" already exists" error which is preventing me from clearing the cache and getting the site working again. I had originally accidentally added a duplicate my_observer class to my config.xml which is what caused the initial problem, and I since removed both instances completely, but I still get the same error. I have removed all instances and mentions of my_observer from the site, but the error still keeps popping up (I use phpstorm to search the entire project for any mention, and it found none).
I have tried flushing the cache through a shell command, but I only get the error 'php_network_getaddresses: getaddrinfo failed: Name or service not known'.
I have empties the var/cache folder and the var/session folder as well, to no avail.
I have cleared the cache in my browser, used another browser, and used incognito mode, all of which did not work either.
I know I basically need to flush the cache to make the site work again, but I basically can't flush the cache until I flush the cache.
Thank goodness I found an answer to my question. My cache is a Redis cache and I used the following commands to flush the cache through CLI (note, I had to install redis-tools in the CLI for this to work):
Pick one of the options below
redis-cli FLUSHDB
redis-cli -n DB_NUMBER FLUSHDB
redis-cli -n DB_NUMBER FLUSHDB ASYNC
redis-cli FLUSHALL
redis-cli FLUSHALL ASYNC
You can find your DB number in app/etc/local.xml.
Here is my source:
https://www.cyberciti.biz/faq/how-to-flush-redis-cache-and-delete-everything-using-the-cli/
I have just upgraded my site from Magento 1.7 to 1.9 and i'm now getting a 500 Internal Server Error. From other posts, I have done the following:
Deleted the maintenance.flag file
Changed permission on index.php to 755
Changed permission on downloader/index.php to 755
Changed permissions recursively on /var to 777
I've also gone through the files and all directories seem to be 755 and all main files '666'.
I'm still getting the 500 Internal Server Error. The bigger problem is that I have no error files in /log to be able to identify the problem. I created the folder /log (because it didn't exist) but no files are in there. I do not have access to the frontend of backend (because of the 500 Internal Server Error) to make sure that logging is turned on.
Any idea how I can try to troubleshoot / get these error logs?
Thanks!
It sounds like you're getting a plain, un-styled 500 Internal Server Error page, which means its your web server that's returning the error. This means any error logging is likely to be in your web server log files, and not PHP or Magento's log files.
You'll need to check with your system administrator to find out
What web server you're running
Where it's log files are
And if you have access to those log files
Common places these files might be are
/var/log/apache2/error_log
/var/log/nginx/...
However, every distribution keeps them in a different place.
This is really weird.
I am trying a clean Teamcity 9.1.1 install but the Data Directory is nowhere to be found.
if I access the Global Settings tab under Administration, it lists "C:\Windows\System32\config\systemprofile.BuildServer" - a folder that doesn't exist.
if I try to browse to that folder, it shows me a range of files; uploading a specific file there instead uploads it to C:\Windows\SysWOW64\config\systemprofile.BuildServer.
there is no teamcity-startup.properties file anywhere - I am unable to customize the location of the data directory.
when I restore a backup, the backup files are instead restored to C:\Users\[user name]\.BuildServer rather than in the correct data directory.
Does anyone has any suggestions on how to regain control of the situation? How can I tell TeamCity which data folder to use?
I resolved the situation by:
stopping TC services;
creating a teamcity-startup.properties in [install folder]\conf with the following content:
teamcity.data.path=D:\\[install folder]\\config
restarting TC services;
restoring my backup.
This restored the 9.1.1 install as well as stabilizing the location of the data directory. After this was done, the subsequent installation of 9.1.7 prompted me to uninstall 9.1.1 first (which it hadn’t done the first time around) and the upgrade succeeded.
I believe the system was already compromised at the beginning, unknown to me, due to the data folder being all over the place. Once that was resolved, everything else fell into place.
I'm writing a project with a lot of static files
Whenever I change a custom.js file, even thought it get changed both in
web/static/assets/custom.js and priv/static/assets/custom.js
When I try to reach the resource I get the old version, which is also most of the times corrupted
I tried:
restarting the server
running brunch build
removing the whole _build directory
changing the files further
clearing browsers cache
using url localhost:4000/assets/js/custom.js -H 'Pragma: no-cache'
Still the server serves old file
Edit
It seems to be an issue with mtime difference between vagrant VM and host.
So the real question is:
How to eliminate that issue?
I'm trying to set up a development server with PuPHPet, which is essentially just a pre-made build of Vagrant with PHP, Nginx and a few other things pre-installed.
I'm having a weird caching issue with my .css files.
When I access my .css file directly at my dev URL, it shows part of the file. This is the file as it was originally before I started editing it. You will notice from my screenshot that I've deleted the entire contents of the file and replaced it with the numbers "12345". When I refresh the .css file in my browser, I see the first 5 characters of the old file. Adding an extra character restores an additional character from the old file.
Restarting nginx does not clear the cache. Ctrl+F5 does not clear the cache. Checking the file contents from vagrant ssh:
[08:11 PM]-[vagrant#precise64]-[/var/www/public/css]-[hg default] B
B$ cat main.css
12345
I can see the file is up to date. The file it's partially displaying simply does not exist. My best guess is it's reading the length of the file on disk, and then pulling the actual contents from memory.
The built-in PHP 5.4 development server does not have this problem, so I'm pretty sure Nginx is the culprit.
How can I get Nginx to behave in a sane fashion?
Most probably it's this know VirtualBox bug with the sendfile system call.
Try disabling sendfile in nginx config:
sendfile off;
(In apache EnableSendfile off)