> > Hi Roberto, > > Aha! I was foolishly only looking in the emperor log. Yes, in the > vassal-specific log, I see this: > > 2016-11-12 18:49:15 Sat Nov 12 18:49:15 2016 - *** > /var/www/www_example_com_wsgi.py has been touched... grace them all > !!! *** > 2016-11-12 18:49:15 ...gracefully killing workers... > > This happened *while NFS was broken*. > > So something about the NFS outage is making the vassal think that the > file has been touched. Does the uWSGI code just use a regular inotify > to monitor the touch_reload files? > >
Hi Giles, so the problema happens because the current use of stat() for the touch_reload. We consider the file 'touched' whenever stat() returns an error (this is for supporting at the same time owner change, mtime change and removal). But during NFS outage it could return EINTR or EIO. The culprit is here: https://github.com/unbit/uwsgi/blob/uwsgi-2.0/core/utils.c#L3436 So, we could gather the return value of stat() and make assumptions about it (like ignoring it during EIO/EINTR). First step would be understanding which error the NFS outage returns in your case. I would add this line: uwsgi_error("DEBUG stat()"); after this one: https://github.com/unbit/uwsgi/blob/uwsgi-2.0/core/utils.c#L3445 -- Roberto De Ioris http://unbit.com _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
