@amarao9 фев 2011 в 22:43

История одного бага

7 мин

8.7K

Системное администрирование *

+157

Комментарии 78

НЛО прилетело и опубликовало эту надпись здесь

@artifex 10 фев 2011 в 00:31

Как-то «угробить 4 часа времени» и «получить массу опыта» не вяжутся друг с другом. Два чая вам за стремление докопаться до сути, это очень ценное качество, уважаю.

@amarao 10 фев 2011 в 01:03

Почему не вяжутся? Я мог не тратить эти 4 часа и спокойно заниматься другой работой (ближе к сути того, за что мне деньги платят). В этом случае я так же бы получил массу опыта, но в другой области. В данном случае это было просто инстинктивное упрямство, которое позволило решить совершенно несущественную проблему, попутно выучив кусочек generic linux'а (вместо узкопрофессиональных вопросов).

@mitnlag 10 фев 2011 в 07:05

Не generic linux'a, а дебиановской скриптовой обвязки.

@amarao 10 фев 2011 в 10:56

Копание в устройстве sysv я считаю всё-таки generic linux. Да, там была и debian-специфика, но когда я тщательно разбирался с порядком запуска скриптов, это всё-таки generic.

@ionicman 10 фев 2011 в 04:50

«Опыт это вещь, появляющаяся непосредственно после того, как была нужна» (С) кто-то мудрый :-D

Так что как раз это вполне вяжется и так обычно и бывает.

@ZiggiPop 10 фев 2011 в 02:29

>При загрузке — успешный запуск раз из пяти, или даже реже.

после этого момента в голову пришло то, что виноват асинхронный маунт nfs. Но статью дочитал, детективная история понравилась, сам бы обошелся «грязным хаком» sleep 5.

Пункты морали понравились, а первый пункт так вообще универсален.

@ekzo 10 фев 2011 в 02:44

эталон отличной статьи[x]

@kyprizel 10 фев 2011 в 03:31

плюс за разбор, минус за то что не проверили конфиг интерфейса до того как копать всё остальное :)

@SkazochNik 10 фев 2011 в 04:03

Если бы всегда знать наверняка, то везде была бы солома.

@vip_delete 10 фев 2011 в 04:31

После таких копаний образуется иммунитет на все баги

@ghisguth 10 фев 2011 в 04:37

А почему бы вместо NFS не использовать rsync + cron? Данные были бы на диске в любой момент.

@flashvoid 10 фев 2011 в 04:46

А я то же незнал про rcS — спасибо вот.

@NickyX3 10 фев 2011 в 04:49

Это бага squeez видимо, в lenny интерфейсы вроде как дефолтно выставлялись в auto (хотя я обычно ручками копирую заготовку для /etc/network/interfaces времен sarge). То есть дефолтную настройку для интерфейса поменяли, а rc скрипт забыли поправить.

@SonicGD 10 фев 2011 в 05:42

Буквально неделю назад ставил Lenny, тоже интерфейсы в hot-plug выставлены.

@NickyX3 10 фев 2011 в 05:43

Ну значи мой шаблон старинный имеет место быть.

@MNU 10 фев 2011 в 10:27

lenny при инсталляции интерфейсы описываются также как и описано в статье.

@NickyX3 10 фев 2011 в 10:40

Меня поражает как некоторые люди, успевают написать баян, не прочитав каменты ниже, и ответы на них

@MNU 10 фев 2011 в 11:09

Уважаемый и где ниже указан данный баян?

ЗЫ. Не для холивара, а тупо интересно (спецом перечитал)

@NickyX3 10 фев 2011 в 11:30

habrahabr.ru/blogs/sysadm/113482/?reply_to=3647027#comment_3646046

@MNU 10 фев 2011 в 14:35

И где написано, что «мой шаблон старинный» имеет отношение к lenny и дефаултовым настройкам?

ЗЫ. Не вижу противоречий, на чем и отланяюсь (флуд не мой стиль).

@grokinn 10 фев 2011 в 05:32

Это прекрасно когда можешь разоблачить любую магию. У меня вот было на lenny сервер подключен к инету и раздает его на локальные компы через NAT и часть сайтов с локальный компов не открывается (набор их варьировался) при этом с самого сервера они прекрасно открывались, ДНС с клиентских машин резолвилось, я все перерыл но так и не смог эту магию разоблачить пришлось ставить сквид и ходить в инет только через него.

@amarao 10 фев 2011 в 07:52

У меня такая забавная проблема была когда «внутренний» трафик шёл по тому же интерфейсу, что внешний, в одном сегменте сети до шлюза, я подозревал там фигню с ARP. После разделения ИП NAT'ирующего узла в отдельную подсеть проблема прошла.

@mihmig 10 фев 2011 в 09:55

Возможно Вам поможет добавление в rc.local строчки:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
(тут ноги растут от mtu-уменьшите его и на клиентских виндовых машинах с помощью drtcp)

@bion 10 фев 2011 в 05:33

Из-за подобных багов продвижение десктопа на линуксе страдает. Особенно мне не нравится сетевой стек убунты и дебиана. Вроде все работает, но нет нет да всплывёт какой-нибудь косячок.

@amarao 10 фев 2011 в 07:55

Послушайте, только обще-брезгливое отношение к виндам останавливает меня от детективных историй подобного рода на виндах.

Худшая история, которая была — это потеря контроллером домена в отдельном узле доверия ко всем установленным сертификатам (включая сертификаты, которыми подписывают обновления виндов) из-за ключа 'safer'. Что это проблема в ключе я выяснил, а вот почему он появляется (аж 4 раза было) — нет. А симптом был простой — «не ставятся обновления». И выяснить глубже не получается, ибо всюду binary shit без сырцов.

Так что 4 часа с полным выяснением причин фигни — это альтернатива «переставить всё нафиг» (без гарантий, что поможет) в виндах.

@AstonMartin 10 фев 2011 в 16:50

В виндах бывают полтергейсты похлеще, только там практически не возможно докопаться до самой сути проблемы.

@adminimus 10 фев 2011 в 17:19

а вот и очередной «разоблачитель мифов о безглючном линуксе» подтянулся :)

@andoriyu 10 фев 2011 в 06:54

Ох уж это наследие SysV.

НЛО прилетело и опубликовало эту надпись здесь

@drunken 10 фев 2011 в 07:15

да, и ведь не зря я всегда после установки переписывал /etc/network/interfaces под себя, по пути меняя hot-plug на auto…

@evgenyk 10 фев 2011 в 07:42

А по моему статья хорошая, но решение в корне неправильное и слишком сложное.

Если один процесс ждет результатов выполнения другого, в многозадачной системе, нужно делать семафор и первый процесс должен его выставлять, а второй проверять.

В данном случае в качестве семафора может служить проверка выхода команды mount. Благо на шел это сделать, как два пальца. Цикл со sleep 1 в теле и проверкой не замонтировалась ли шара.

@amarao 10 фев 2011 в 07:57

Моё решение не меняет кода initscripts, если бы я их поменял, то нарвался бы на конфликт во время ближайшего обновления пакета.

@evgenyk 10 фев 2011 в 08:02

А зачем менять код в инитскриптс? При чем пакеты?

@amarao 10 фев 2011 в 08:07

А как вы предлагаете отлавливать NFS? Или просто в цикле ждать появления строчки в mtab? В этом случае есть большие шансы никогда не закончить загрузку: NFS-сервер лёг (mount отвалился и загрузка продолжилась, скрипт йок и повис), искать PID конкретного mount.nfs — кулхакерство с шансами «найти не то», следить за полнотой каталога — нарваться на подмонтированную пустую шару и уйти в бесконечный цикл.

@evgenyk 10 фев 2011 в 08:10

Как всегда, ограничить максимальное количество циклов и вываливаться с руганью.
Это не кулхакерство, это как раз нормальный путь при программировании, если есть что-то внешнее, что может быть, а может не быть, только проверка. В любой книжке написано большими буквами.

@amarao 10 фев 2011 в 10:57

Зачем? Приведённый workaround полностью решает задачу, причём штатными средствами дистрибутива, без привнесения собственного функционала, в котором ещё и ошибки могут быть.

@evgenyk 10 фев 2011 в 14:57

Проверять нужно обязательно. Потому, что Вы обошли одну проблему, а в данном месте может быть еще десять. И опять будете гадать.

@amarao 10 фев 2011 в 16:18

Что проверять? Я вообще не знаю, что ответить на фразу «а может быть десять».

Что нужно проверять? Какие проблемы могут быть? Или вы о том, что «в программах бывают ошибки»? Спасибо, я об этом не догадывался.

Мой тезис: воркэраунд, построенный на смещении конфигурации в ожидаемый скриптом штатный режим работы лучше, чем собственный код, реализующий некий новый функционал по ожиданию сетевого события.

@evgenyk 10 фев 2011 в 16:32

Конкретно в Вашем случае, смотря как Вы напишете скрипт, нужно проверять или то, что интерфейс поднят, или доступность ресурса.
Вы обошли гонку, а завтра будет поврежден сетевой кабель, или еще что, и опять будете искать час.
Любое удаленный ресурс должно проверяться и говорить «Ресурс недоступен» в случае ошибки.

@amarao 10 фев 2011 в 17:39

Я не «обошёл гонку», я изменил конфигурацию так, чтобы меня не затрагивал баг в скрипте. В отсутствие бага initscripts правильно отрабатывают проблемы на NFS при выключенном ASYNC: до таймаута идёт попытка подмонтировать, если нет, система продолжает работать с неподмонтированной шарой.

Я вывел систему из-под действия бага (причём вывел гарантированно, т.к. нашёл суть бага и поменял конфиг так, чтобы этот баг не мог проявиться); вы же предлагаете вместо выведения из области действия бага сделать костыль, который должен устранять последствия бага.

Разница, надеюсь, видна? Второй вариант чище и универсальнее (т.к. поведение системы не поменяется после устранения бага, а костыль может и начать мешать).

@evgenyk 11 фев 2011 в 08:18

> баг в скрипте

Я не думаю, что это баг в скрипте. Имнно такое поведение задокументировано (прописывание в allow-hotplug). (http://www.debian.org/doc/manuals/reference/ch05.en.html)
Видимо это было сделано сознательно, я даже догадываюсь почему. В таком случае, Ваш путь допустим в качестве быстрого хака, но недопустим в качестве рекомендации.

@amarao 11 фев 2011 в 10:28

Не поленился, прочитал.

Почему внесение интерфейса в auto является «недопустимым в качестве рекомендации»?

@evgenyk 11 фев 2011 в 11:11

Потому, что это не бага, а сделано специально. Люди, следуя такой Вашей рекомендации будут обходить «багу» путем, противоречащим полиси и ловить проблемы в других местах.

@amarao 11 фев 2011 в 11:37

Чего???

Ещё раз, что неправильного в прописывании интерфейса в auto?

     Lines  beginning with the word "auto" are used to identify the physical
       interfaces to be brought up when ifup is run with the -a option.  (This
       option  is  used by the system boot scripts.)  Physical interface names
       should follow the word "auto" on the same line.  There can be  multiple
       "auto"  stanzas.   ifup  brings  the  named  interfaces up in the order
       listed.

Нам нужно, чтобы хост поднимал интерфейс? Да. Запрещает ли это прописывать хост в hotplug? Нет, так как одно другому не мешает.

Как говорит reportbug при жалобе на нарушение полиси «без указания на точное утверждение, которому противоречит действие, багрепорт не рассматривается».

Итак, вопрос: какому пункту полиси противоречит прописывание интерфейса в auto?

@amarao 10 фев 2011 в 23:41

И что я должен сделать, если ресурс недоступен? Танцевать джигу?

ТЗ прочтите, для чего это делалось.

@evgenyk 11 фев 2011 в 08:24

Ждать, проверять снова, если прошел заданный Вами таймаут, вываливаться с записью в лог и стдэрр.
Стандартное поведение для вещей, которые могут быть недоступны или заняты другими процессами.

@amarao 11 фев 2011 в 10:30

А почему это должен делать я в самописном скрипте, если это умеет делать сама ОС в процессе монтирования? А ошибка зафиксируется сама собой, так как rc.local запускается с -e и невозможность запустить процесс с шары будет зафиксирована штатными же средствами?

Ещё раз, почему я должен выкинуть уже сделанное и сделать сам и с нуля?

@evgenyk 11 фев 2011 в 11:14

Сможете выкинуть внятное сообщение об ошибке и что-то сделать.

@amarao 11 фев 2011 в 11:42

Что-то сделать? Что именно можно сделать, когда NFS-шара не доступна, а приложение находится именно на ней?

Или, если хотите, вот вам другой вопрос: всегда ли я должен, прописывая запуск приложения с подмонтированной файловой системы в rc.local осуществлять тщательные проверки в скрипте на:

1) наличие сетевых интерфейсов в системе
2) Состояние сетевых интерфейсов (UP, RUNNING)
3) Проверку доступности шлюза
4) Работу ARP
5) Наличие модулей для подмонтирования данной ОС, их совместимость с текущим ядром.
6) Адекватность настроек modprobe
7) Успешность монтирования
8) Отсутствие сообщений об ошибках от portmap, nfs.
9) Наличие нужных файлов на шаре
10) Вменяемость настроек ld

И это всё для запуска строчки /opt/foobar/runtest из rc.local?

Мне кажется, ваше предложение ведёт к неконструктивным последствиям.

@Pilat 10 фев 2011 в 17:37

Проверять надо. В конце концов, программе, использующей ресурс, всё равно по какой причине его нет — главное знать что его нет. Это стоило бы делать даже без описанного бага.

Кстати. Как Вам удалось запомнить последовательность поиска места ошибки? Вы записывали что делали или просто память хорошая? Как вариант методики поиска бага очень неплохое руководство получилось.

@amarao 10 фев 2011 в 17:42

Часть по памяти, часть в mindmap'е, часть у меня в ЖЖ в бессвязных постах и руганью (там первая часть поиска).

На самом деле примерно 50% моей работы состоит из подобного, то есть в этом случае главной проблемой было не найти и решить проблему, а сформулировать, что проблема есть и поймать её для достоверного воспроизведения.

Сейчас у меня висит куда более грустная проблема с пухнущим по памяти openvswitch при определённых условиях, и как эту проблему решать я не знаю, т.к. не могу пока что воспроизвести обстоятельства.

@aim 12 фев 2011 в 08:52

это даже не workaround строго говоря. это просто выполнение неких неявных требований при работе с nfs на данном дистрибутиве данной версии с данными пакетами.

НЛО прилетело и опубликовало эту надпись здесь

@amarao 10 фев 2011 в 10:58

Не имеет смысла, т.к. NFS-шары и так особо в /etc/fstab обрабатываются и монтируются позже локальных FS, позже инициализации сети. Эта опция нужна для всяких diskless DRBD, ISCSI initiator'ов и т.д.

@MNU 10 фев 2011 в 10:39

Трабла с прописыванием интерфейсов по дефолду через hot-plug видимо существует давно. В lenny это присутствует точно. Из-за этого в частности не корректно отрабатывается пердергивание интерфейсов через скрипт /etc/init.d/networking. Не всегда имеется возможность на серверах дергать кабели чтобы вступили в силу изменения в конфиге. И как уже упоминалось в статье лечится прописыванием параметра auto или обоих сразу.

@NickyX3 10 фев 2011 в 10:59

Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.

картинта с Бартом у доски (с)

@MNU 10 фев 2011 в 11:07

Ваши предложения Сер?

Ребутить весь сервер чтобы прописать влан или добавить алис?

Или простой в 3-5 минут это не простой?

@NickyX3 10 фев 2011 в 11:19

Одна ошибка где-нибудь в конфиге, и сервер не поднимает интерфейс. А сервер на другом конце города, или вообще в другом.
Что — отменили ifdown ethX; ifup ethX?

@MNU 10 фев 2011 в 14:31

Риск есть всегда, но волка боятся в лес не ходить ;)

@amarao 10 фев 2011 в 13:22

«никогда» — громко сказано. Бывают ещё IMPI с IP-KVM.

@NickyX3 10 фев 2011 в 13:49

Да я как бы в курсе за всякие iLO, IMM2. Но в те времена когда я вывел это правило — у меня не было таких серверов

@eaa 10 фев 2011 в 15:56

Я никогда не буду делать /etc/init.d/iptables на удаленном сервере :)

@aim 12 фев 2011 в 08:53

а что мешает это делать в скрине? ;)

@burdakovd 10 фев 2011 в 11:03

У меня похожие проблемы (не race condition, но всё же) были c 6to4 на селектеловском облаке.

Прописал 6to4 интерфейс в /etc/network/interfaces.

Но получилось, что чтобы поднялся интерфейс 6to4 — нужен модуль ядра, который загружается с NFS. А монтирование NFS запускается только после поднятия сети.

Решил поднятием 6to4 интерфейса отдельным init скриптом вместо auto в /etc/network/interfaces.

@amarao 10 фев 2011 в 11:42

Да, я знаю об этой проблеме (она же так же затрагивает модули нестандартных ФС, таких, как xfs/jfs) — их нужно монтировать в rc.local.

@Hellbot 10 фев 2011 в 12:34

А мне было интересно посмотреть на получившийся mindmap у решения (хотя наверное я слишком многого прошу)

@amarao 10 фев 2011 в 13:20

Я поздно на mindmap переключился, вот то, что было:

desunote.ru/pub/mm/nfs/

@LaFut 10 фев 2011 в 14:37

> «гонке условий» (race condition)
странный перевод, по русски это ru.wikipedia.org/wiki/Состояние_гонки

@adminimus 10 фев 2011 в 17:28

а ещё можно послать багрепорт и решить эту проблему самым правильным методом — устранить проблему. При этом, чем лучше (и по сути) вы опишете проблему, тем больше вероятность, что её решат

увы, даже самое подробное описание с бектрейсами из отладчика и даже с готовым патчем абсолютно не гарантирует, что багрепортом будут заниматься, а не отложат в дальний угол до лучших времен. Так что надеяться только на этот способ не стоит, лучше все же починить самому (хотя бы временно), а потом уже оформить багрепорт.

@SunCho00 10 фев 2011 в 19:49

Уважаемый, а вы когда нибудь слышали про autofs? Пора прекращать забивать гвозди микроскопом
есть даже статейка на вашем любимом дебиан-вики wiki.debian.org/AutoFs
только они зачем-то скрестили ёжа с ужом приплетя сюда udev