That is exactly the issue. Seeing what the "reload" did to the memory
(starting a new worker process) was the culprit. I was thinking the
configuration reload should just refresh what's in memory, but it clearly
doubles the requirement of memory and must wait until the previous child
can stop grace
Hello!
On Fri, Jul 27, 2018 at 10:56:38AM -0400, Shaun Tarves wrote:
> Here are the relevant parts of our configuration:
>
> worker_processes 1;
> pid/var/run/nginx.pid;
> events {
> worker_connections 512;
> }
> http {
> server {
> listen xx.xx.xx.xx:443 default_server ssl;
Here are the relevant parts of our configuration:
worker_processes 1;
pid/var/run/nginx.pid;
events {
worker_connections 512;
}
http {
server {
listen xx.xx.xx.xx:443 default_server ssl;
ssl on;
ssl_certificate /opt/xxx.pem;
ssl_certificate_key /opt/xxx.key
ssl_
Hello!
On Thu, Jul 26, 2018 at 04:16:11PM -0400, Shaun Tarves wrote:
> We are trying to use nginx to support the DoD PKI infrastructure, which
> includes many DoD and contractor CRLs. The combined CRL file is over 350MB
> in size, which seems to crash nginx during a reload (at least on Red Hat
>
Shaun,
Can you post a snippet on how you include crl into your configuration
and 'ps aux | grep nginx' output, please?
The wild guess is that you include the crl several times. And on reload
you get twice as many workers as there are usually.
You can try moving ssl_crl statement into http{}
Hi,
We are trying to use nginx to support the DoD PKI infrastructure, which
includes many DoD and contractor CRLs. The combined CRL file is over 350MB
in size, which seems to crash nginx during a reload (at least on Red Hat
6). Our cert/key/crl set up is valid and working, and when only including
