Quantcast
Channel: Nginx Forum
Viewing all 53287 articles
Browse latest View live
↧

Re: [PATCH 2 of 2] Contrib: vim syntax, update core module directives.

December 29, 2017, 1:56 pm
$
0
0
Hello!

On Thu, Dec 28, 2017 at 12:07:54PM +0200, Gena Makhomed wrote:

> # HG changeset patch
> # User Gena Makhomed <gmm@csdoc.com>
> # Date 1514455265 -7200
> # Thu Dec 28 12:01:05 2017 +0200
> # Node ID 16674bef9168f70962cafb451a0dd212b37d9c61
> # Parent 215684d20d906135281b2540149d354b6e4bb852
> Contrib: vim syntax, update core module directives.
>
> Removed non-existent directives and directive redefinitions.

[...]

Committed, thanks.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
↧
Search

Re: unit-0.3 beta

December 29, 2017, 2:52 pm
$
0
0
Всех с наступающим НГ.

Много раз себя ловил на мысли когда смотрел на JSON конфиг Unit, почему вы решили сервисы называть application?

Я понимаю что NGINX Unit - это Application Server, но уже устоялись такие понятия как microservice, которые часто настраиваются как отдельные Unit для systemd.service + systemd.socket, там application называются service.

Это конечно не критично, но согласитесь что будет всем удобно использовать одну терминологию.
↧
↧

Re: unit-0.3 beta

December 29, 2017, 3:34 pm
$
0
0
On Saturday, 30 December 2017 01:52:52 MSK S.A.N wrote:
> Всех с наступающим НГ.
>
> Много раз себя ловил на мысли когда смотрел на JSON конфиг Unit, почему вы
> решили сервисы называть application?
>
> Я понимаю что NGINX Unit - это Application Server, но уже устоялись такие
> понятия как microservice, которые часто настраиваются как отдельные Unit для
> systemd.service + systemd.socket, там application называются service.
>
> Это конечно не критично, но согласитесь что будет всем удобно использовать
> одну терминологию.
>

Как по вашему, firefox - это сервис или приложение? Можете обосновать почему?

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: unit-0.3 beta

December 29, 2017, 5:43 pm
$
0
0
> Как по вашему, firefox - это сервис или приложение? Можете обосновать
> почему?

Я же не ради холивара это писал :)
Клиентские GUI приложения сервисами сложно назвать, но для меня:
PHP-FPM - это сервис
Node.js - это сервис
Python WSGI - это сервис
Go Server - это сервис

Возможно у меня systemd головного мозга, но в вашем конфиге, раздел "listeners" я понимаю как директивы для systemd.socket и соответственно "applications" у меня ассоциируется с директивами для systemd.service, мне так проще унифицировать свои знание и ваше название Unit очень помогает сделать связь с unit от systemd.

В идеале мне (думаю и многим тоже) будет удобно если все аналогичные директивы из unit.nginx и systemd будут иметь одинаковые название.
↧

Re: unit-0.3 beta

December 29, 2017, 6:56 pm
$
0
0
On Saturday, 30 December 2017 04:43:31 MSK S.A.N wrote:
> > Как по вашему, firefox - это сервис или приложение? Можете обосновать
> > почему?
>
> Я же не ради холивара это писал :)
> Клиентские GUI приложения сервисами сложно назвать, но для меня:
> PHP-FPM - это сервис
> Node.js - это сервис
> Python WSGI - это сервис
> Go Server - это сервис

И Unit может быть сервисом, а запускает он приложения. =)


>
> Возможно у меня systemd головного мозга, но в вашем конфиге, раздел
> "listeners" я понимаю как директивы для systemd.socket и соответственно
> "applications" у меня ассоциируется с директивами для systemd.service, мне
> так проще унифицировать свои знание и ваше название Unit очень помогает
> сделать связь с unit от systemd.

Для меня wordpress.com - это сервис, а WordPress тот, что набор php
скриптов - это приложение. И именно настройка интерпретации данного
набора скриптов и производится в объекте "applications".

Тот же GUI для Firefox отрисовывается с помощью других промежуточных
служб, X-сервера, драйвера и т.д., и там даже может учавствовать некий
протокол, а всё это может быть физически разнесено по разным машинам.
А для WordPress интерфейс рисуется с помощью браузера, того же Firefox.
Поэтому всё не так просто и однозначно.

Под сервисами, как правило, понимают те приложения, которые выполняют
некую служебную, то бишь сервисную функцию для других приложений.
Поскольку именно такую функцию чаще всего выполняют системные службы,
то и systemd, и многие другие init-системы пользуются данной терминологией.

В любом случае сервисное приложение - это тоже приложение. Как утверждает
словарь: application - a program or piece of software designed to fulfil
a particular purpose. "a database application". Так, например в зависимости
от архитектуры, приложение может быть монолитным или микросервисным, с ним
может непосредственно взаимодействовать пользователь, а могут другие
приложения.

Иными словами сервис - это более узкий термин, определяющий выполняемую
приложением роль. Возможно он идеально подходит для systemd, но я бы не
стал называть большинство веб-приложений сервисами.

В Unit-е используется нейтральный термин, не навязывающий определенной
роли или архитектуры для приложения.


>
> В идеале мне (думаю и многим тоже) будет удобно если все аналогичные
> директивы из unit.nginx и systemd будут иметь одинаковые название.
>

О нет, не хотелось бы переизобретать systemd. Пусть systemd и дальше
запускает сервисы, а Unit будет заниматься запуском веб-приложений.

В любом случае, спасибо вам за идею, я её принял к сведению. Безусловно,
конфигурация должна быть интуитивно понятной для пользователей и правильный
выбор терминологии крайне важен. Например, в ранних версиях Unit объект
"listeners" назывался "sockets", но это вызвало всеобщее неприятие и в
итоге он был переименован.

В случае же "applications" -> "services" - это первый подобный запрос, а
текущая терминология устраивает в том числе американскую часть компании,
для которой это родной язык, поэтому вероятность одобрения не велика.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
↧

Missing /etc/nginx/sites-available/default

December 29, 2017, 9:02 pm
$
0
0
i was following a tutorial to setup nginx on ubuntu 16.04

i am supposed to edit a this file : /etc/nginx/sites-available/default
but its not there , there is no folder like sites-available
what i should do ?
↧

Re: unit-0.3 beta

December 30, 2017, 2:03 am
$
0
0
> Иными словами сервис - это более узкий термин, определяющий выполняемую приложением роль.
> Возможно он идеально подходит для systemd, но я бы не стал называть большинство веб-приложений сервисами.

Я абсолютно согласен с этим определением.
Но хочу обратить внимание что основная цель Systemd в том чтобы сделать из любого Линукс приложения, работающий Линукс сервис.
Возможно я ошибаюсь, но основная цель Nginx.Unit - сделать из любого бекенд приложения, работающий веб-сервис, или нет?

Давайте посмотрим что предпологаеться указывать в разделе "applications"

"applications":
{
"blogs": {блог это же веб-сервис},
"wiki": {тоже больше похоже на веб-сервис},
"shopping_cart": {это важный веб-сервис, который можно разбить на микросервисы},
"chat": {100% веб-сервис}
}

Я как бекенд разработчик мыслю так, я разрабатываю бекенд приложения и мне нужен Nginx.Unit чтобы сделать из моего бекенд приложения, работающий веб сервис.

> текущая терминология устраивает в том числе американскую часть компании, для которой это родной язык, поэтому вероятность одобрения не велика.

Просто им нужно предложить более короткое название Services, которое более точно отражает основную миссию Nginx.Unit - создавать веб-сервисы из бекенд-приложений.

В любом случаи, с наступающим НГ!
↧

Re: unit-0.3 beta

December 30, 2017, 3:58 am
$
0
0
Здравствуйте!

Я не использую systemd и для меня перечисленное - приложения. Если unit -
сервер приложений, то, очевидно, он запускает приложения.

С уважением, Иван Прокудин.

В письме от суббота, 30 декабря 2017 г. 4:43:31 MSK пользователь S.A.N
написал:
> > Как по вашему, firefox - это сервис или приложение? Можете обосновать
> > почему?
>
> Я же не ради холивара это писал :)
> Клиентские GUI приложения сервисами сложно назвать, но для меня:
> PHP-FPM - это сервис
> Node.js - это сервис
> Python WSGI - это сервис
> Go Server - это сервис
>
> Возможно у меня systemd головного мозга, но в вашем конфиге, раздел
> "listeners" я понимаю как директивы для systemd.socket и соответственно
> "applications" у меня ассоциируется с директивами для systemd.service, мне
> так проще унифицировать свои знание и ваше название Unit очень помогает
> сделать связь с unit от systemd.

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
Search

Re: апстрим режет запросы?

December 30, 2017, 11:48 am
$
0
0
Добрый вечер,

Всех с наступающим!

Подскажите, пожалуйста, если я strace-ом смотрю что делает nginx воркер и вижу

38935 write(150, "2017/12/30 19:15:54 [error] 38935#0: *487552235 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: gta, request: \"POST /wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc478a8bbe83a4b03488002a19cac4ac78dab2ac86637d4b HTTP/1.1\", upstream: \"https://213.212.78.37:443/wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc4"..., 577 <unfinished …>

то это по-любому проблема апстрима или все-таки есть шанс бага на моей стороне?

Евгений

> On 7 Dec 2017, at 16:25, Eugene Toropov <eugene.toropov@gmail.com> wrote:
>
> Добрый день,
>
> Ситуация следующая:
>
> 1) В error логе куча ошибок вида:
>
> 2017/12/07 13:19:32 [error] 44862#0: *11393098096 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: xxx, request: "POST xxx HTTP/1.1", upstream: “xxxx", host: “xxx:8080"
>
> 2) В access логе соотв запросы имеют код ответа 502 и $request_time всегда около 4 секунд?
>
> Это похоже на то, что апстрим режет запросы rps фильтром?
>
> Евгений
>
>

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
↧

Re: Error response body not sent if upload is incomplete

December 30, 2017, 12:44 pm
$
0
0
Find the server logs below. It does seem to match what you've quoted.

Do you think the upstream server (uwsgi) is the one not returning the body?

I was able to fix this by consuming the request body in my application before returning the response. However, I'm still wondering how nginx is supposed to behave in such situations.

Log for the request with the larger file:
api-server_1 | [pid: 21|app: 0|req: 1/1] 172.19.0.1 () {38 vars in 601 bytes} [Sat Dec 30 11:14:46 2017] POST / => generated 54 bytes in 2 msecs (HTTP/1.1 403) 2 headers in 78 bytes (1 switches on core 0)
api-server_1 | 2017/12/30 11:14:46 [error] 12#12: *1 readv() failed (104: Connection reset by peer) while reading upstream, client: 172.19.0.1, server: , request: "POST / HTTP/1.1", upstream: "uwsgi://unix:///tmp/uwsgi.sock:", host: "0.0.0.0:5000"
api-server_1 | 172.19.0.1 - - [30/Dec/2017:11:14:46 +0000] "POST / HTTP/1.1" 403 25 "-" "curl/7.55.1" "-"

With the smaller file:
api-server_1 | 172.19.0.1 - - [30/Dec/2017:11:15:41 +0000] "POST / HTTP/1.1" 403 79 "-" "curl/7.55.1" "-"
api-server_1 | [pid: 20|app: 0|req: 3/4] 172.19.0.1 () {38 vars in 595 bytes} [Sat Dec 30 11:15:41 2017] POST / => generated 54 bytes in 1 msecs (HTTP/1.1 403) 2 headers in 78 bytes (1 switches on core 0)
↧

Nginx manage multiple https website with keepalived

December 30, 2017, 5:12 pm
$
0
0
I already submit an issue in keepalived github issue page
https://github.com/acassen/keepalived/issues/731 and stackoverflow. Paste
again for more people's help.

I want to use Nginx to manager multiple https website, refer to nginx
document http://nginx.org/en/docs/http/configuring_https_servers.html
(Name-based
HTTPS servers section), one method is to assign a separate IP for every
HTTPS servers. And in our environment, this is the only method.

Due to single-point issue, I want to use keepalived to manage master-backup
Nginx node. The logic is:

1. Setup master/backup nginx node

2. Master nginx will assign multiple vip via keepalived

3. Master nginx will be up, backup nginx is down. (due to backup nginx has
no vip, start will fail)

4. If master nginx is down, vip transfer to backup node, backup nginx start.

I test in Centos 7 with keepalived v1.3.5, but meet some issue.
Configurationmaster node

global_defs {
router_id LVS_DEVEL}

vrrp_script chk_nginx {
script "/usr/sbin/pidof nginx"
interval 3
!weight -5
rise 1
fall 2}

vrrp_instance VI_1 {
state MASTER
interface eth1
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.2.16
192.168.2.17
}
track_script {
chk_nginx
}

notify /etc/keepalived/notify_keepalived.sh
notify_stop "systemctl stop nginx"}

backup node

global_defs {
router_id LVS_DEVEL}

vrrp_script chk_nginx {
script "/usr/sbin/pidof nginx"
interval 3
!weight -5
rise 1
fall 2}

vrrp_instance VI_1 {
state BACKUP
interface eth1
virtual_router_id 51
priority 96
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.2.16
192.168.2.17
}
track_script {
chk_nginx
}

notify /etc/keepalived/notify_keepalived.sh
notify_stop "systemctl stop nginx"}

check script:

$ cat /etc/keepalived/notify_keepalived.sh#!/bin/bash
TYPE=$1
NAME=$2
STATE=$3

echo $STATE > /tmp/k.log:case $STATE in
"MASTER") systemctl start nginx
exit 0
;;
"BACKUP") systemctl stop nginx
exit 0
;;
"FAULT") systemctl stop nginx
exit 0
;;
*) echo "ipsec unknown state"
exit 1
;;esac

method 1

If unset weight, keepalived startup will check nginx pid immediately, even
I set interval and fall parameter. Master nginx won't enter master state,
all node will enter fault state. No master will elect and no active nginx
will come up.

Dec 30 04:59:00 localhost systemd: Starting LVS and VRRP High Availability
Monitor... Dec 30 04:59:00 localhost Keepalived[20039]: Starting Keepalived
v1.3.5 (03/19,2017), git commit v1.3.5-6-g6fa32f2 Dec 30 04:59:00 localhost
Keepalived[20039]: Unable to resolve default script username
'keepalived_script' - ignoring Dec 30 04:59:00 localhost Keepalived[20039]:
Opening file '/etc/keepalived/keepalived.conf'. Dec 30 04:59:00 localhost
systemd: PID file /var/run/keepalived.pid not readable (yet?) after start.
Dec 30 04:59:00 localhost Keepalived[20040]: Starting Healthcheck child
process, pid=20041 Dec 30 04:59:00 localhost Keepalived[20040]: Starting
VRRP child process, pid=20042 Dec 30 04:59:00 localhost systemd: Started
LVS and VRRP High Availability Monitor. Dec 30 04:59:00 localhost
Keepalived_healthcheckers[20041]: Opening file
'/etc/keepalived/keepalived.conf'. Dec 30 04:59:00 localhost
Keepalived_vrrp[20042]: Registering Kernel netlink reflector Dec 30
04:59:00 localhost Keepalived_vrrp[20042]: Registering Kernel netlink
command channel Dec 30 04:59:00 localhost Keepalived_vrrp[20042]:
Registering gratuitous ARP shared channel Dec 30 04:59:00 localhost
Keepalived_vrrp[20042]: Opening file '/etc/keepalived/keepalived.conf'. Dec
30 04:59:00 localhost Keepalived_vrrp[20042]: VRRP_Instance(VI_1) removing
protocol VIPs. Dec 30 04:59:00 localhost Keepalived_vrrp[20042]: WARNING -
script `systemctl` resolved by path search to `/usr/bin/systemctl`. Please
specify full path. Dec 30 04:59:00 localhost Keepalived_vrrp[20042]:
SECURITY VIOLATION - scripts are being executed but script_security not
enabled. Dec 30 04:59:00 localhost Keepalived_vrrp[20042]: Using LinkWatch
kernel netlink reflector... Dec 30 04:59:00 localhost
Keepalived_vrrp[20042]: VRRP sockpool: [ifindex(3), proto(112), unicast(0),
fd(10,11)] Dec 30 04:59:00 localhost Keepalived_vrrp[20042]:
/usr/sbin/pidof nginx exited with status 1 Dec 30 04:59:01 localhost
Keepalived_vrrp[20042]: VRRP_Instance(VI_1) Now in FAULT state Dec 30
04:59:03 localhost Keepalived_vrrp[20042]: /usr/sbin/pidof nginx exited
with status 1 Dec 30 04:59:06 localhost Keepalived_vrrp[20042]:
/usr/sbin/pidof nginx exited with status 1
method 2

If uncomment weigth, startup works fine. Master node assign vip and master
nginx startup. Backup nginx is down.

However, when I shutdown master nginx, master node priority (100-5) >
backup node (96-5). Although master nginx is down, but vip still be in
master node.
method 3

set master weight -5, set backup weigth 2.

1. Startup keepalived, master node get vip, master nginx start. Backup
nginx is down.
2. Shutdown master nginx, master node priority 95 < backup node 96,
backup node get vip, backup nginx start.
3. Shutdown backup nginx, master node priority 95 < backup node
96(98-2), backup still hold vip, no active nginx come up.

For this scenario, program startup depends on vip, how to manage HA?

Thanks.
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
↧

Re: апстрим режет запросы?

December 30, 2017, 10:16 pm
$
0
0
SNI ? Покажите снифер?

On Dec 31, 2017 12:47 AM, "Eugene Toropov" <eugene.toropov@gmail.com> wrote:

> Добрый вечер,
>
> Всех с наступающим!
>
> Подскажите, пожалуйста, если я strace-ом смотрю что делает nginx воркер и
> вижу
>
> 38935 write(150, "2017/12/30 19:15:54 [error] 38935#0: *487552235 upstream
> prematurely closed connection while reading response header from upstream,
> client: 192.168.42.32, server: gta, request: \"POST /wbsapi/
> RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529f
> cc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc478a8bbe
> 83a4b03488002a19cac4ac78dab2ac86637d4b HTTP/1.1\", upstream: \"
> https://213.212.78.37:443/wbsapi/RequestListenerServlet?sha=
> 42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e
> 39c7dadaafaceefd2e59dc4"..., 577 <unfinished …>
>
> то это по-любому проблема апстрима или все-таки есть шанс бага на моей
> стороне?
>
> Евгений
>
> > On 7 Dec 2017, at 16:25, Eugene Toropov <eugene.toropov@gmail.com>
> wrote:
> >
> > Добрый день,
> >
> > Ситуация следующая:
> >
> > 1) В error логе куча ошибок вида:
> >
> > 2017/12/07 13:19:32 [error] 44862#0: *11393098096 upstream prematurely
> closed connection while reading response header from upstream, client:
> 192.168.42.32, server: xxx, request: "POST xxx HTTP/1.1", upstream: “xxxx",
> host: “xxx:8080"
> >
> > 2) В access логе соотв запросы имеют код ответа 502 и $request_time
> всегда около 4 секунд?
> >
> > Это похоже на то, что апстрим режет запросы rps фильтром?
> >
> > Евгений
> >
> >
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: апстрим режет запросы?

December 31, 2017, 12:14 am
$
0
0
А можно здесь поподробнее? Я не настолько крут в strace.

Евгений

> 31 дек. 2017 г., в 9:14, Илья Шипицин <chipitsine@gmail.com> написал(а):
>
> SNI ? Покажите снифер?
>
>> On Dec 31, 2017 12:47 AM, "Eugene Toropov" <eugene.toropov@gmail.com> wrote:
>> Добрый вечер,
>>
>> Всех с наступающим!
>>
>> Подскажите, пожалуйста, если я strace-ом смотрю что делает nginx воркер и вижу
>>
>> 38935 write(150, "2017/12/30 19:15:54 [error] 38935#0: *487552235 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: gta, request: \"POST /wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc478a8bbe83a4b03488002a19cac4ac78dab2ac86637d4b HTTP/1.1\", upstream: \"https://213.212.78.37:443/wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc4"..., 577 <unfinished …>
>>
>> то это по-любому проблема апстрима или все-таки есть шанс бага на моей стороне?
>>
>> Евгений
>>
>> > On 7 Dec 2017, at 16:25, Eugene Toropov <eugene.toropov@gmail.com> wrote:
>> >
>> > Добрый день,
>> >
>> > Ситуация следующая:
>> >
>> > 1) В error логе куча ошибок вида:
>> >
>> > 2017/12/07 13:19:32 [error] 44862#0: *11393098096 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: xxx, request: "POST xxx HTTP/1.1", upstream: “xxxx", host: “xxx:8080"
>> >
>> > 2) В access логе соотв запросы имеют код ответа 502 и $request_time всегда около 4 секунд?
>> >
>> > Это похоже на то, что апстрим режет запросы rps фильтром?
>> >
>> > Евгений
>> >
>> >
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
↧

Re: апстрим режет запросы?

December 31, 2017, 2:26 am
$
0
0
On Saturday, 30 December 2017 22:46:51 MSK Eugene Toropov wrote:
> Добрый вечер,
>
> Всех с наступающим!
>
> Подскажите, пожалуйста, если я strace-ом смотрю что делает nginx воркер и вижу
>
> 38935 write(150, "2017/12/30 19:15:54 [error] 38935#0: *487552235 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: gta, request: \"POST /wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc478a8bbe83a4b03488002a19cac4ac78dab2ac86637d4b HTTP/1.1\", upstream: \"https://213.212.78.37:443/wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc4"..., 577 <unfinished …

Вы видите, что nginx пишет в лог файл.
Никакой ценности это наблюдение не представляет.


>
>
> то это по-любому проблема апстрима или все-таки есть шанс бага на моей стороне?
>

Сообщение в логе указывает на проблему в апстриме. Откуда сомнения?

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: апстрим режет запросы?

December 31, 2017, 4:16 am
$
0
0
> On 31 Dec 2017, at 13:24, Валентин Бартенев <vbart@nginx.com> wrote:
>
> On Saturday, 30 December 2017 22:46:51 MSK Eugene Toropov wrote:
>> Добрый вечер,
>>
>> Всех с наступающим!
>>
>> Подскажите, пожалуйста, если я strace-ом смотрю что делает nginx воркер и вижу
>>
>> 38935 write(150, "2017/12/30 19:15:54 [error] 38935#0: *487552235 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: gta, request: \"POST /wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc478a8bbe83a4b03488002a19cac4ac78dab2ac86637d4b HTTP/1.1\", upstream: \"https://213.212.78.37:443/wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc4"..., 577 <unfinished …
>
> Вы видите, что nginx пишет в лог файл.
> Никакой ценности это наблюдение не представляет.
>
>
>>
>>
>> то это по-любому проблема апстрима или все-таки есть шанс бага на моей стороне?
>>
>
> Сообщение в логе указывает на проблему в апстриме. Откуда сомнения?
>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Понятно, спасибо. Сомнения оттуда, что поддержка апстрима пишет ничего такого не видит на своей стороне. Видимо просто не заглядывают глубоко. Будем с ними разбираться. Еще раз с наступающим и спасибо!

Евгений
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧
Search

Наследование директив установки заголовков

December 31, 2017, 8:34 pm
$
0
0
Знатоки, поясните пожалуйста, с какой целью в nginx сделано так, что add_header и proxy_set_header «наследуются с предыдущего уровня при условии, что на данном уровне не описаны свои директивы»?

Это же ужасно неудобно — хочется задать ряд общих заголовков на уровне http/server, а в location'ах добавлять отдельные заголовки.
Стоит прозевать и установить единственный заголовок в location'е — отваливаются все вышеустановленные.

Наверное, у такого решения есть большие преимущества, но прояснить их для себя не могу.
↧

Dynamic nginx configuration without reloading

December 31, 2017, 10:08 pm
$
0
0
Hi All,

We are currently building a shared hosting platform for parts of our clients. We are using nginx as our web servers running on the nodes.

Everything works fine. However, we discovered that when we are hosting more than a certain amount of sites (typically around 300 conf files), reloading nginx conf is extremely slow.

Is there a way to dynamically configure nginx (e.g. adding/removing server blocks) without reloading nginx?


Thanks & Best Regards
House
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
↧
↧

Re: Наследование директив установки заголовков

January 1, 2018, 4:36 am
$
0
0
On Monday, 1 January 2018 07:34:48 MSK gz wrote:
> Знатоки, поясните пожалуйста, с какой целью в nginx сделано так, что
> add_header и proxy_set_header «наследуются с предыдущего уровня при условии,
> что на данном уровне не описаны свои директивы»?
>
> Это же ужасно неудобно — хочется задать ряд общих заголовков на уровне
> http/server, а в location'ах добавлять отдельные заголовки.
> Стоит прозевать и установить единственный заголовок в location'е —
> отваливаются все вышеустановленные.
>
> Наверное, у такого решения есть большие преимущества, но прояснить их для
> себя не могу.
>

1. Это не отличается от всех остальных директив в nginx, т.е. это единое
правило, делающее конфигурацию единообразной.

При этом, если раньше какую-то директиву можно было задать только один
раз, а позже стало возможным описывать несколько таких директив, то
существующие конфигурации от этого не ломаются, ибо правило наследования,
что у одной директивы, что у нескольких - одниковое.

2. А про остальное рассказывает Игорь:
https://www.youtube.com/watch?v=fcG-7k20oG8

Если кратко, это делает конфигурацию однозначной. Работает ровно то,
что видите в конкретном блоке. Вам не нужно просматривая все уровни
вложенности и в уме суммировать списки директив.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
↧

Re: Error response body not sent if upload is incomplete

January 1, 2018, 12:36 pm
$
0
0
Hello!

On Sat, Dec 30, 2017 at 06:04:26PM -0500, naktinis wrote:

> Find the server logs below. It does seem to match what you've quoted.
>
> Do you think the upstream server (uwsgi) is the one not returning the body?
>
> I was able to fix this by consuming the request body in my application
> before returning the response. However, I'm still wondering how nginx is
> supposed to behave in such situations.
>
> Log for the request with the larger file:
> api-server_1 | [pid: 21|app: 0|req: 1/1] 172.19.0.1 () {38 vars in 601
> bytes} [Sat Dec 30 11:14:46 2017] POST / => generated 54 bytes in 2 msecs
> (HTTP/1.1 403) 2 headers in 78 bytes (1 switches on core 0)
> api-server_1 | 2017/12/30 11:14:46 [error] 12#12: *1 readv() failed (104:
> Connection reset by peer) while reading upstream, client: 172.19.0.1,
> server: , request: "POST / HTTP/1.1", upstream:
> "uwsgi://unix:///tmp/uwsgi.sock:", host: "0.0.0.0:5000"
> api-server_1 | 172.19.0.1 - - [30/Dec/2017:11:14:46 +0000] "POST /
> HTTP/1.1" 403 25 "-" "curl/7.55.1" "-"
>
> With the smaller file:
> api-server_1 | 172.19.0.1 - - [30/Dec/2017:11:15:41 +0000] "POST /
> HTTP/1.1" 403 79 "-" "curl/7.55.1" "-"
> api-server_1 | [pid: 20|app: 0|req: 3/4] 172.19.0.1 () {38 vars in 595
> bytes} [Sat Dec 30 11:15:41 2017] POST / => generated 54 bytes in 1 msecs
> (HTTP/1.1 403) 2 headers in 78 bytes (1 switches on core 0)

The "readv() failed (104: Connection reset by peer)" error
indicate that there is a backend problem which makes it impossible
to reliably receive the body of the response. To make it possible
for nginx to receive the body, backend must either read the whole
body, or implement proper connection teardown (in nginx, this is
called lingering_close, see http://nginx.org/r/lingering_close).

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
↧

Re: Dynamic nginx configuration without reloading

January 1, 2018, 1:00 pm
$
0
0
Hello!

On Mon, Jan 01, 2018 at 12:07:04AM -0600, House Lee wrote:

> We are currently building a shared hosting platform for parts of
> our clients. We are using nginx as our web servers running on
> the nodes.
>
> Everything works fine. However, we discovered that when we are
> hosting more than a certain amount of sites (typically around
> 300 conf files), reloading nginx conf is extremely slow.
>
> Is there a way to dynamically configure nginx (e.g.
> adding/removing server blocks) without reloading nginx?

Short answer:

No.

Long answer:

There are ways to do limited reconfiguration without reloading,
notably the API module[1], available as part of our commercial
subscription. It won't, however, allow to add or remove server{}
blocks.

That is, to add or remove server{} blocks you have to do a
configuration reload. Note though, that in many cases you can
actually avoid adding or removing server{} blocks. Multiple
identical or slightly different sites can be handled using a
single server{} block with multiple server names.

Note well that 300 looks a way too low for "extremely slow",
you may want to check what actually makes it so slow. In
particular, make sure that:

- you do have enough memory, as reload creates a new set of
worker processes and this more or less doubles memory used by
nginx;

- you don't have problems with DNS and/or no names are used in a
configuration. Slow DNS can easily make loading a
configuration with multiple names extremely slow due to blocking
DNS lookups during configuration parsing.

[1] http://nginx.org/en/docs/http/ngx_http_api_module.html

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
↧
Viewing all 53287 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>