Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: nginx-0.8.39
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
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru
|