nginx-0.8.39

[Богун Дмитрий]

В Чтв, 03/06/2010 в 03:05 +0400, Maxim Dounin пишет:
> > > > >Есть ещё проблема при binary upgrade совмещённом с аналогичным
> > > > >изменением конфига.
> > > > Есть и ещё проблема с оставшимися от hard reboot сокетами
> > > 
> > > Отличить "оставшиеся от hard reboot" сокеты от сокетов открытых 
> > > другими процессами - не представляется возможным.  
> > А нужно ли их отличать?
> > Если кто-то настроил две разные программы слушать на одном сокете, это
> > его личные проблемы...
> > 
> > Т.е. мы имеем ситуацию, когда сокет в неизвестном состоянии принадлежит
> > нам(нашей программе - т.е. nginx'у). Из это следует, что если мы смогли
> > "завладеть" пид-файлом, то мы "должны" обеспечить работоспособность того
> > что прописано в конфиге. Для чего может потребоваться удалить предыдущий
> > unix-сокет с ФС.
> 
> В nginx'е нет никаго "завладевания" pid-файлом, он стартует если 
> смог прочитать конфиг и сделать bind() на listen-сокеты.  В рамках 
> tcp-сокетов это работает отлично - при старте (попытке старта) мы 
> не ломаем работающий сервис (если вдруг он есть), и замечательно 
> стартуем если никого нет.
Нет "завладевания" пид-файлом, но есть условие после которого он
гарантированно запускается, что по моему равнозначно.
> Unix-сокеты в этом смысле ушибленные на голову, всмысле - совсем 
> другие.  Чтобы сделать для них то же самое - нужно дополнительно 
> изобретать mandatory locking.  Которого в unix-системах по 
> большому счёту нет.
> 
> Кроме того, мне например совсем не нравится идея совершения 
> деструктивных действий при старте.  Если кто-то случайно написал в 
> конфиге listen unix:/etc/passwd; - это совсем не повод оный файл 
> стирать.  Сейчас, правда, то же самое будет для pid-файла, но это 
> не значит что количество подобных мест надо увеличивать.
Разве нельзя сделать на него lstat() и посмотреть что это такое? Это не
pid-файл, который как и /etc/passwd является обычным файлом, а сокет,
который довольно легко отличить. 

Правда от того, кто пишет такое в конфигах, никакой защиты не сделаешь.
Тогда прийдется делать защиту и от "rm -rf /", что есть неправильно.

> > Живость предыдущего инкарнации nginx'а(владельца существующего сокета) к
> > этому моменту не играет определяющей роли - существующие по нему
> > соедининия(если он был жив), будут обработаны. А потенциально новые
> > соединений уже обработаем Мы, после создания нового сокета.
> 
> Это - выварачивание наизнанку существующей модели поведения.  При 
> этом следует иметь ввиду что:
> 
> 1. C tcp-сокетами подобная модель просто невозможна, т.е. вообще.  
> Если жить так - придётся тщательно крепить крышу.
Вы сами сказали, что unix сокеты "иные" и модель tcp сокетов к ним не
применима, может быть имеет смысл использовать для них другую модель при
которой они будут нормально работать.
> 2. Мой опыт показывает что подобная модель чревата бОльшим 
> количеством проблем, чем существующая.  В частности - проблемы в 
> модели "не запускаться если тапки заняты" обычно возникают как 
> следствие осмысленных действий администратора (и он где-то рядом 
> чтобы всё исправить), в то время как в модели "стереть и 
> запуститься" - как следствие забывчивости и/или неосторожности (и 
> не факт что есть кому править, а если и есть - то не факт что он 
> сможет или вообще заметит проблему).
Но ведь оно так не работает. Если бы оно выругалось и отказалось
запускаться/перезапускаться, тогда никаких вопросов. А сейчас оно просто
запускается и невозможность забиндить unix сокет его нисколько не
смущает.
> 3. Существующая логика превращается в "стереть и запуститься" для 
> unix-сокетов дописыванием пары строчек в startup script.  Обратное 
> невозможно.
А это нарушает принцип "непрерывности" обслуживания. Причем перерыв в
обслуживании, в тяжелых случаях(сокет удалили, а новый нгинкс по
какой-либо причине отказался стартовать), может быть весьма
существенным.

Дело конечно ваше, но по моему невозможно сделать единую систему для TCP
и unix сокетов.