4

I'm trying to write a process that invalidates the cache on nginx (and doesn't re-warm the cache).

By default, nginx has 700 on its cache files. The closest setting that I could find was:

proxy_store_access user:rw group:rw all:r;

However, that applies to proxy stores, not caches.

So, how do I tell nginx to create the cache files as 777?

I'm currently running nginx/1.5.8 on ubuntu 12.

Homer6
  • 221
  • 2
  • 7

2 Answers2

2

Ok, so, to answer your specific question, the you need to set the umask to 000. If you want, I can give you those instructions. But I don't think that's what you want. Seriously.

Incidentally, the proxy_store_access configuration affects files created by both the proxy_store and proxy_cache systems (I checked this in the source code).

I don't mean to be rude, but I don't think you want to do what you're suggesting. I suspect you want to clean out your nginx chache regularily. If you look at the documentation here: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_path you'll see that there nginx should handle invalidating your cache to keep it under a certain size.

Now, if you still want to write a process that invalidates (I assume you mean deletes) the cache, here's a different option. If this is to run as a cronjob, put it in the nginx user's crontab. Also, there are ways to use sudo to give someone limited access to elevated permissions. Lastly, if you're really coding up a special program, then look into the setuid (aka suid) bit on the executable.

Good Luck. Does this help?

etherfish
  • 1,757
  • 10
  • 12
  • Umask 000 will only allow the file to be created 777 if the application requests it which is not normally the case. – user9517 Jan 21 '14 at 06:47
  • Agreed, that's why I mentioned that the proxy_store_access directive he'd mentioned is actually used as the mode bits in the few open() calls in the code. Again, I really don't think he wants the files created with 777 permissions in the first place. Why would cache files warrant an execute bit? – etherfish Jan 21 '14 at 06:50
  • 3
    Cluelessness is the usual reason for settin 777 perms ;) – user9517 Jan 21 '14 at 06:53
  • @etherfish Thanks for your reply. I had originally tested the proxy_store_access setting and it didn't result in 777 for the cache files. Can you link the location in the source please? Also, I'm not invalidating to manage the size. I'm invalidating to create a system where no data is ever stale. So, as soon as the data is changed on the source server, it asynchronously communicates with the caching proxy to delete only that file. PS. You're not rude :-) That's Iain's job – Homer6 Jan 21 '14 at 09:42
  • Homer6, I believe that this option is meant for your exact situation: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_purge also, the proxy_cache_revalidate settings seems relevant. I'm sorry, but I don't think I can help you much beyond this point. – etherfish Jan 21 '14 at 11:40
  • Also, I misled you. I was confused by a bunch of function pointers. The proxy_store_access field will override the mode bits passed to ngx_open_file but not when the handler is a cache. With a cache, NGX_FILE_DEFAULT_ACCESS is used which is 0644. Sorry. :( – etherfish Jan 21 '14 at 11:43
  • 1
    Hi @etherfish, thanks for following up. If NGX_FILE_DEFAULT_ACCESS is used, then why are the files 700? – Homer6 Jan 21 '14 at 19:43
0

The point is moot anyways.

According to this answer and the forum post from Igor Sysoev (author of nginx), deleting the cache files alone will not be sufficient to clear the cache because of shared memory.

So, I'm relaxing one of my requirements and allowing the cache to be cleared by warming it up. I'm now making https requests with the Pragma: no-cache header.

Ideally, I wouldn't have to warm it up in order to clear the cache. But, I don't have a solution to only clear the cache for a given URI.

Community
  • 1
Homer6
  • 221
  • 2
  • 7
  • I believe 2 posts you link to state the opposite: deleting the cache files *is* sufficient. – Max Ivanov Jul 02 '16 at 07:20
  • You're right. They do state that. However, when I tested it, the cache was not cleared when I deleted the files. Are you able to confirm that deleting the files guarantees that the cache is invalidated? – Homer6 Jul 02 '16 at 11:06
  • Yes, I've just checked and cache is reset after I manually rm files. And there's a Wordpress plugin for Nginx fastcgi cache support (https://wordpress.org/plugins/nginx-helper/) which I believe implements "Purge Entire Cache" the same way (deleting all files within cache dir). – Max Ivanov Jul 03 '16 at 08:30