Can nginx "events" block be configured in an include file?

[Dave Sherohman <dave@sherohman.org>]

tl;dr:  I need to increase worker_connections on my nginx servers, but
don't want to edit the debian-provided nginx.conf due to that causing
future upgrade hassles.  Is this possible?


Long version:

I've got a couple servers running a somewhat convoluted web app
deployment, with nginx at the front end.  Every so often, one of the
nginx instances will lock up and start logging "768 worker_connections
are not enough" messages on every request.

After some searches and double-checking that there aren't any loops in
my nginx config, I've come to the conclusion that 768 is an absurdly low
default for production servers - one source said that "over 9000" is
appropriate for most sites that see significant traffic.

So I'm thinking I should probably raise it.  However, when I tried
raising it from conf.d, nginx failed to start, with the error

[emerg] 25402#25402: "events" directive is not allowed here in /etc/nginx/conf.d/mysite.conf:1

conf.d/mysite.conf contains only:
---
events {
  worker_connections 10240;
  # multi_accept on;
}
---

I also tried moving that config file to modules-enabled/ and it at least
gave me a different error message:

[emerg] 14914#14914: "events" directive is duplicate in /etc/nginx/nginx.conf:6

so it apparently accepted my events block, then choked on the default
one.

Is there any way to accomplish this using only new files of my own
creation, while leaving all debian-provided config files in a pristine
state?



I know I could change it directly in /etc/nginx/nginx.conf, but

a) That would potentially generate conflicts with new debian-provided
   versions of nginx.conf whenever the package is upgraded

b) My site-specific config files are generated from templates, meaning
   that I'd then need to keep the template in sync with any debian-
   provided changes, or go outside the existing system and have to
   remember to manually tweak nginx.conf every time I make a new server
   or upgrade an existing one

and I would greatly prefer a one-time change which doesn't lead to
either of those ongoing maintenance concerns.

-- 
Dave Sherohman