nginx-0.8.39

[Maxim Dounin]

Hello!

On Wed, Jun 02, 2010 at 11:50:32PM +0300, Богун Дмитрий wrote:

> В Срд, 02/06/2010 в 23:04 +0400, Maxim Dounin пишет:
> > > 02.06.2010 20:49, Maxim Dounin wrote:
> > > >Есть ещё проблема при binary upgrade совмещённом с аналогичным
> > > >изменением конфига.
> > > Есть и ещё проблема с оставшимися от hard reboot сокетами
> > 
> > Отличить "оставшиеся от hard reboot" сокеты от сокетов открытых 
> > другими процессами - не представляется возможным.  
> А нужно ли их отличать?
> Если кто-то настроил две разные программы слушать на одном сокете, это
> его личные проблемы...
> 
> Т.е. мы имеем ситуацию, когда сокет в неизвестном состоянии принадлежит
> нам(нашей программе - т.е. nginx'у). Из это следует, что если мы смогли
> "завладеть" пид-файлом, то мы "должны" обеспечить работоспособность того
> что прописано в конфиге. Для чего может потребоваться удалить предыдущий
> unix-сокет с ФС.

В nginx'е нет никаго "завладевания" pid-файлом, он стартует если 
смог прочитать конфиг и сделать bind() на listen-сокеты.  В рамках 
tcp-сокетов это работает отлично - при старте (попытке старта) мы 
не ломаем работающий сервис (если вдруг он есть), и замечательно 
стартуем если никого нет.

Unix-сокеты в этом смысле ушибленные на голову, всмысле - совсем 
другие.  Чтобы сделать для них то же самое - нужно дополнительно 
изобретать mandatory locking.  Которого в unix-системах по 
большому счёту нет.

Кроме того, мне например совсем не нравится идея совершения 
деструктивных действий при старте.  Если кто-то случайно написал в 
конфиге listen unix:/etc/passwd; - это совсем не повод оный файл 
стирать.  Сейчас, правда, то же самое будет для pid-файла, но это 
не значит что количество подобных мест надо увеличивать.

> Живость предыдущего инкарнации nginx'а(владельца существующего сокета) к
> этому моменту не играет определяющей роли - существующие по нему
> соедининия(если он был жив), будут обработаны. А потенциально новые
> соединений уже обработаем Мы, после создания нового сокета.

Это - выварачивание наизнанку существующей модели поведения.  При 
этом следует иметь ввиду что:

1. C tcp-сокетами подобная модель просто невозможна, т.е. вообще.  
Если жить так - придётся тщательно крепить крышу.

2. Мой опыт показывает что подобная модель чревата бОльшим 
количеством проблем, чем существующая.  В частности - проблемы в 
модели "не запускаться если тапки заняты" обычно возникают как 
следствие осмысленных действий администратора (и он где-то рядом 
чтобы всё исправить), в то время как в модели "стереть и 
запуститься" - как следствие забывчивости и/или неосторожности (и 
не факт что есть кому править, а если и есть - то не факт что он 
сможет или вообще заметит проблему).

3. Существующая логика превращается в "стереть и запуститься" для 
unix-сокетов дописыванием пары строчек в startup script.  Обратное 
невозможно.

Maxim Dounin