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
В Чтв, 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 сокетов.
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru
|