Hello!

On Thu, Jun 25, 2020 at 04:05:19PM +0300, Gena Makhomed wrote:

> On 25.06.2020 14:48, Илья Шипицин wrote:
>
> > > /etc/systemd/nspawn/1.nspawn
> > >
> > > [Exec]
> > > LimitNOFILE=infinity
>
> > > /etc/nginx/nginx.conf
> > >
> > > worker_rlimit_nofile 262144;
>
> > в этом месте вы думаете, что воркер сам себе проставил такой лимит на
> > количество файлов.
>
> > посмотрите в /proc/<pid>/limits , действительно ли там значения, которые вы
> > ожидаете или нет
> > у нас было, что systemd применял свои лимиты поверх
>
> # cat /proc/205/cmdline
> nginx: worker process
>
> # grep "Max open files" /proc/205/limits
> Max open files 262144 262144 files

А у master-процесса что?

Если я правильно понимаю код ядра линукса, ETOOMANYREFS означает,
что количество одновременно отправляемых файловых дескрипторов
превышает лимит на количество дескрипторов в отправляющем
процессе, в данном случае - в мастере, ибо никто больше файловые
дескрипторы с помощью sendmsg() не шлёт. Собственно, pid процесса
можно смотреть сразу в сообщении об ошибке.

Ну и отвечая на исходный вопрос про "насколько критична эта
ошибка": приведённая ошибка как минимум означает, что система
общения между мастером и рабочими процессами больше не работает.
То есть отвечать на запросы nginx будет, а скажем reload сделать -
уже нормально не сможет. То есть приблизительно как и со всеми
ошибками уровня alert: "что-то развалилось и непредсказуемо
глючит, сделайте что-нибудь".

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