Hi there,

it sounds like you have found a workaround for your production system,
so that it a good thing.

The probably-not-satisfactory but maybe-adequate thing is for you to
create a new directory whenever the current directory has (say) 100 files,
and put new files into the new directory.

If you are willing to do some more testing, perhaps the problem can be
identified and the "proper" solution designed.

Since this will involve restarting nginx with known-broken config,
you may be happier doing it on a non-production system.

So: one test can be about the number of files -- if "195 is good; 197
is bad" is true in general.

What I think you have reported is that with 195 files, things work; if
you add the new config to the end of a current file, things work; but if
you add the new config to new files instead of current files, things fail.

On a system that shows that behaviour, can you have the config in the
two new files so that it fails; and then delete five other files so
that you have less than 195 files again.

Does that work or fail? If it works, it suggests that there may be a
file-count limit; if it fails, it suggests that the problem is not with
the number of files.


Another test can be about the config. With the 195-files case where it
works, with the new config at the end of a current file, can you write
the output of "nginx -T" to a file -- for example:

nginx -T > 195-works

And then with the 197-files case where it fails, can you do something
similar:

nginx -T > 197-fails

Then you can play "spot-the-difference" between the two files, such as
by doing

diff -u 195-works 197-fails

What you should see there is probably exactly the same content with +
and - marks at the start, as the new config is probably in different
places in the full config. If there is anything other than that, it may
be interesting.

(Also: the diff output should be mostly just the new config, so should
be much smaller than the full config, and should have much less private
information, so may be easier to edit before sharing, if that is a useful
thing to do.)

Maybe one or other of those tests will show something that will help
identify the source of the problem.

If you can afford the effort to try that, it may help the next person
who has the same issue.

Cheers,

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx