t;
> On Sat, May 03, 2025 at 06:14:19PM +0200, Sébastien Rebecchi via nginx
> wrote:
> >
> > Is there a way to update Nginx on the fly while new nginx was configured
> > with a different --prefix than was the old one?
>
> You may want following the "Upgrading Ex
Hello,
Is there a way to update Nginx on the fly while new nginx was configured
with a different --prefix than was the old one?
Thanks,
Sébastien.
___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
server :443
>
> }
>
> location / {
> proxy_pass http://main_upstream;
> error_page 502 @try_secondary;
>
> }
>
> location @try_secondary {
> proxy_pass https://secondary_upstream;
>
> }
>
> ____
> Fro
Hello,
I understand that within an upstream block, some servers can be marked as
backup, meaning NGINX will only use them if all primary servers fail.
In my case, I have some servers running over HTTP and would like to
configure HTTPS servers as backups. However, since an upstream can only use
on
Hello.
Is there a limit on the number of servers that can be added in a upstream
context?
Best regards,
Sébastien.
___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
Hello
I have 2 questions
1. When is it better to use random load-balancing strategy rather than the
default round-robin one (and vice-versa)?
2. Is there a way to be notified when a server is marked as down (max_fails
reached during fail_timeout)? I can't see anything as such in error logs
Than
à 17:08, Sébastien Rebecchi
a écrit :
> Hello
>
> Reading this doc seems unclear to me
> https://nginx.org/en/docs/control.html#upgrade
>
> According to it, we should do
>
> kill -USR2 $nginxPid
> kill -WINCH $nginxPid
> kill -QUIT $nginxPid
>
> with $nginxP
Thanks Roman!
Le jeu. 18 juil. 2024 à 15:53, Roman Arutyunyan a écrit :
> Hello,
>
> On 11 Jul 2024, at 1:12 PM, Roman Arutyunyan wrote:
>
> Hi Sébastien,
>
> On 9 Jul 2024, at 5:52 PM, Sébastien Rebecchi
> wrote:
>
> Hi!
>
> We are using nginx a lot in o
Hello
Reading this doc seems unclear to me
https://nginx.org/en/docs/control.html#upgrade
According to it, we should do
kill -USR2 $nginxPid
kill -WINCH $nginxPid
kill -QUIT $nginxPid
with $nginxPid the pid of the old nginx.
But doing that seems not good cause we have a strange behaviour that
Thanks Roman, I am expecting that :)
Le jeu. 11 juil. 2024 à 11:12, Roman Arutyunyan a écrit :
> Hi Sébastien,
>
> On 9 Jul 2024, at 5:52 PM, Sébastien Rebecchi
> wrote:
>
> Hi!
>
> We are using nginx a lot in our company for high HTTP/2 workloads.
>
> I saw fre
Hi!
We are using nginx a lot in our company for high HTTP/2 workloads.
I saw freenginx has applied a bugfix in their last mainline release 1.27.1,
see https://freenginx.org/en/CHANGES
*) Bugfix: graceful shutdown of old worker processes might be delayed
when using HTTP/2.
Thank
Hello
Just to close that conversation, it seems this was an error of our devops
in charge of alerting, who was using curl in a bad way.
Best regards,
Sébastien
Le lun. 6 mai 2024 à 11:33, Sébastien Rebecchi a
écrit :
> Hello!
>
> There is nothing regarding this issue in nginx logs.
écrit :
> Hello!
>
> On Sat, May 04, 2024 at 07:31:43PM +0200, Sébastien Rebecchi wrote:
>
> > Hello
> >
> > What does it mean when nginx returns an http status code 0?
> >
> > We see that cause we monitor nginx response status code, which is used as
> >
Hello
What does it mean when nginx returns an http status code 0?
We see that cause we monitor nginx response status code, which is used as
front of our apps. The apps themselves can not return 0, only 200 or 500.
So it seems issue here comes from nginx itself which can not process the
connection
Hello
As I understand we better replace all proxy_pass to pass when upstream
server is localhost, but pass does not work with remote upstreams.
Is that right?
Sébastien
Le ven. 19 avr. 2024 à 09:38, Kirill A. Korinsky a
écrit :
> On Fri, 19 Apr 2024 03:14:44 +0200,
> Fabiano Furtado Pessoa Coe
fall is a log level above notice. Try setting error log
> to a more verbose one, maybe?
>
> Regards,
> Igor.
>
>
> On 28/03/2024 18:27, Sébastien Rebecchi wrote:
>
> Hi Igor,
>
> Thanks for the answer.
>
> I really got that message 'signal process started'
gt; Also the 'start' and 'reconfiguring' messages from the master process.
> There should be a similar sequence somewhere in your logs.
> Having these logs may help explaining what happens on a reload.
>
> Kind regards,
> Igor.
>
> On 26/03/2024 12:41, Sébastie
explain the reason for connection resets.
>
> Kind regards,
> Igor.
>
> On 25/03/2024 12:31, Sébastien Rebecchi wrote:
>
> Hello
>
>
> I have an issue with nginx closing prematurely connections when reload is
> performed.
>
>
> I have some nginx servers configu
Hello
I have an issue with nginx closing prematurely connections when reload is
performed.
I have some nginx servers configured to proxy_pass requests to an upstream
group. This group itself is composed of several servers which are nginx
themselves, and is configured to use keepalive connection
Hello,
What is the good rule of thumbs for setting the number of keepalive
connections to an upstream group?
1. https://www.nginx.com/blog/performance-tuning-tips-tricks/
in this blog, the writer seems to recommend a constant value of 128, no
real explanation why it would fit whatever the number
20 matches
Mail list logo
