Opened 7 years ago

Closed 7 years ago

#1235 closed defect (invalid)

open_file_cache issues with symlinks

Reported by: reezer@… Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.10.x
Keywords: http open_file_cache Cc:
uname -a: FreeBSD xxx 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0: Mon Oct 24 06:55:27 UTC 2016 amd64
nginx -V: nginx version: nginx/1.10.3
built with OpenSSL 1.0.2k 26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/ --error-log-path=/var/log/nginx/error.log --user=www --group=www --with-file-aio --with-ipv6 --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_image_filter_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_stub_status_module --with-http_sub_module --with-pcre --with-http_v2_module --with-stream --with-stream_ssl_module --with-threads --with-mail --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --with-mail_ssl_module --with-http_ssl_module --add-module=/wrkdirs/usr/ports/www/nginx/work/ngx_brotli-ada972b


It appears that nginx doesn't handle symlinks that get updated, ie. by moving a new symlink on their spot correctly.

To reproduce simply create an aliased directory and put a couple of files in there and create a symlink whose target changes between these files. In my case I had a couple of hundred files and would iterate over them once per minute. Occasionally requests to them would result in older files to be returned. It looks like nginx doesn't notice the change. The reason might be that the target file doesn't change, but where the symlink targets to does.

open_file_cache max=1000 inactive=2h;
open_file_cache_errors on;
open_file_cache_min_uses 1;
open_file_cache_valid 1h;

Turning it off fixes the issue. Also I run with worker_processes 8. There were no errors logged.

Change History (2)

comment:1 by reezer@…, 7 years ago

Might be more of a caveat than a bug, but then it should maybe be mentioned in the documentation.

comment:2 by Maxim Dounin, 7 years ago

Resolution: invalid
Status: newclosed

With open_file_cache_valid 1h; nginx will cache any open files for 1 hour unconditionally, and will only re-validate them after 1 hour, see open_file_cache_valid documentation. Changing files once per minute with such a setting simply doesn't make sense, nginx certainly won't notice.

Note: See TracTickets for help on using tickets.