Stalled cache updating - what does it mean?

Server NGINX
1

Hello,
I have a pretty basic PHP / fastcgi setup with a fastcgi cache as
follows:

fastcgi_cache_key “$scheme$request_method$host$request_uri”;
fastcgi_cache_lock on;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache MAINCACHE;
fastcgi_cache_valid 5m;

I’m using nginx from the nginx.org Debian repository and building from
source, adding the geoip and ngx_cache_purge modules.

nginx version: nginx/1.5.7
built by gcc 4.7.2 (Debian 4.7.2-5)
TLS SNI support enabled

Every so often I’ll get a couple of lines in the log like the following:

2013/12/09 15:59:34 [alert] 14218#0: *10450047 stalled cache updating,
error:0 while closing request, client: x.236.101.34, server:
x.x.101.37:80
2013/12/09 15:59:34 [alert] 14218#0: *10450055 stalled cache updating,
error:0 while closing request, client: x.236.101.34, server:
x.x.101.37:80
2013/12/09 15:59:34 [alert] 14218#0: *10450099 stalled cache updating,
error:0 while closing request, client: x.236.101.34, server:
x.x.101.37:80

This usually occurs after a client requests a script which issues some
internal requests to the site itself (wp-cron).

As it’s log level alert, it seems serious, but I can’t seem to notice
anything wrong as a result. What exactly does this alert mean and is it
something I need to be worried about? I’ve since moved the script to an
offline cron job to see if this helps, but I’m still curious exactly
what
this means.

Thanks,

Rich.

2

Hello!

On Tue, Dec 10, 2013 at 11:24:33AM +0100, Richard S. wrote:

I’m using nginx from the nginx.org Debian repository and building from
2013/12/09 15:59:34 [alert] 14218#0: *10450055 stalled cache updating,
offline cron job to see if this helps, but I’m still curious exactly what
this means.

The message means that nginx detected an internal problem - the
cache cleanup callback was called on a request termination, and
the r->cache->updating flag, which should be cleared at this
point, is still set. User-visible results are most likely a cache
item which will not be updated, or a cache lock which will apear
to be always set (and requests to a cache item only handled only
after a timeout).

I would suggest to test if you are able to reproduce the problem
without 3rd party modules. If you are, it would be interesting to
see full configuration and a debug log, see
Debugging | NGINX.

–
Maxim D.
http://nginx.org/