Pull to refresh

Comments 78

UFO just landed and posted this here
Как-то «угробить 4 часа времени» и «получить массу опыта» не вяжутся друг с другом. Два чая вам за стремление докопаться до сути, это очень ценное качество, уважаю.
Почему не вяжутся? Я мог не тратить эти 4 часа и спокойно заниматься другой работой (ближе к сути того, за что мне деньги платят). В этом случае я так же бы получил массу опыта, но в другой области. В данном случае это было просто инстинктивное упрямство, которое позволило решить совершенно несущественную проблему, попутно выучив кусочек generic linux'а (вместо узкопрофессиональных вопросов).
Не generic linux'a, а дебиановской скриптовой обвязки.
Копание в устройстве sysv я считаю всё-таки generic linux. Да, там была и debian-специфика, но когда я тщательно разбирался с порядком запуска скриптов, это всё-таки generic.
«Опыт это вещь, появляющаяся непосредственно после того, как была нужна» (С) кто-то мудрый :-D

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

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

Пункты морали понравились, а первый пункт так вообще универсален.
плюс за разбор, минус за то что не проверили конфиг интерфейса до того как копать всё остальное :)
Если бы всегда знать наверняка, то везде была бы солома.
После таких копаний образуется иммунитет на все баги
А почему бы вместо NFS не использовать rsync + cron? Данные были бы на диске в любой момент.
Это бага squeez видимо, в lenny интерфейсы вроде как дефолтно выставлялись в auto (хотя я обычно ручками копирую заготовку для /etc/network/interfaces времен sarge). То есть дефолтную настройку для интерфейса поменяли, а rc скрипт забыли поправить.
Буквально неделю назад ставил Lenny, тоже интерфейсы в hot-plug выставлены.
Ну значи мой шаблон старинный имеет место быть.
lenny при инсталляции интерфейсы описываются также как и описано в статье.
Меня поражает как некоторые люди, успевают написать баян, не прочитав каменты ниже, и ответы на них
Уважаемый и где ниже указан данный баян?

ЗЫ. Не для холивара, а тупо интересно (спецом перечитал)
И где написано, что «мой шаблон старинный» имеет отношение к lenny и дефаултовым настройкам?

ЗЫ. Не вижу противоречий, на чем и отланяюсь (флуд не мой стиль).
Это прекрасно когда можешь разоблачить любую магию. У меня вот было на lenny сервер подключен к инету и раздает его на локальные компы через NAT и часть сайтов с локальный компов не открывается (набор их варьировался) при этом с самого сервера они прекрасно открывались, ДНС с клиентских машин резолвилось, я все перерыл но так и не смог эту магию разоблачить пришлось ставить сквид и ходить в инет только через него.
У меня такая забавная проблема была когда «внутренний» трафик шёл по тому же интерфейсу, что внешний, в одном сегменте сети до шлюза, я подозревал там фигню с ARP. После разделения ИП NAT'ирующего узла в отдельную подсеть проблема прошла.
Возможно Вам поможет добавление в rc.local строчки:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
(тут ноги растут от mtu-уменьшите его и на клиентских виндовых машинах с помощью drtcp)
Из-за подобных багов продвижение десктопа на линуксе страдает. Особенно мне не нравится сетевой стек убунты и дебиана. Вроде все работает, но нет нет да всплывёт какой-нибудь косячок.
Послушайте, только обще-брезгливое отношение к виндам останавливает меня от детективных историй подобного рода на виндах.

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

Так что 4 часа с полным выяснением причин фигни — это альтернатива «переставить всё нафиг» (без гарантий, что поможет) в виндах.
В виндах бывают полтергейсты похлеще, только там практически не возможно докопаться до самой сути проблемы.
а вот и очередной «разоблачитель мифов о безглючном линуксе» подтянулся :)
UFO just landed and posted this here
да, и ведь не зря я всегда после установки переписывал /etc/network/interfaces под себя, по пути меняя hot-plug на auto…
А по моему статья хорошая, но решение в корне неправильное и слишком сложное.

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

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

Как всегда, ограничить максимальное количество циклов и вываливаться с руганью.
Это не кулхакерство, это как раз нормальный путь при программировании, если есть что-то внешнее, что может быть, а может не быть, только проверка. В любой книжке написано большими буквами.
Зачем? Приведённый workaround полностью решает задачу, причём штатными средствами дистрибутива, без привнесения собственного функционала, в котором ещё и ошибки могут быть.
Проверять нужно обязательно. Потому, что Вы обошли одну проблему, а в данном месте может быть еще десять. И опять будете гадать.
Что проверять? Я вообще не знаю, что ответить на фразу «а может быть десять».

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

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

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

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

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

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

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

Ещё раз, что неправильного в прописывании интерфейса в 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?
И что я должен сделать, если ресурс недоступен? Танцевать джигу?

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

Ещё раз, почему я должен выкинуть уже сделанное и сделать сам и с нуля?
Сможете выкинуть внятное сообщение об ошибке и что-то сделать.
Что-то сделать? Что именно можно сделать, когда 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?

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

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

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

Сейчас у меня висит куда более грустная проблема с пухнущим по памяти openvswitch при определённых условиях, и как эту проблему решать я не знаю, т.к. не могу пока что воспроизвести обстоятельства.
это даже не workaround строго говоря. это просто выполнение неких неявных требований при работе с nfs на данном дистрибутиве данной версии с данными пакетами.
UFO just landed and posted this here
Не имеет смысла, т.к. NFS-шары и так особо в /etc/fstab обрабатываются и монтируются позже локальных FS, позже инициализации сети. Эта опция нужна для всяких diskless DRBD, ISCSI initiator'ов и т.д.
Трабла с прописыванием интерфейсов по дефолду через hot-plug видимо существует давно. В lenny это присутствует точно. Из-за этого в частности не корректно отрабатывается пердергивание интерфейсов через скрипт /etc/init.d/networking. Не всегда имеется возможность на серверах дергать кабели чтобы вступили в силу изменения в конфиге. И как уже упоминалось в статье лечится прописыванием параметра auto или обоих сразу.
Я никогда не буду делать /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 на удаленном сервере.

картинта с Бартом у доски (с)
Ваши предложения Сер?

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

Или простой в 3-5 минут это не простой?
Одна ошибка где-нибудь в конфиге, и сервер не поднимает интерфейс. А сервер на другом конце города, или вообще в другом.
Что — отменили ifdown ethX; ifup ethX?
Риск есть всегда, но волка боятся в лес не ходить ;)
«никогда» — громко сказано. Бывают ещё IMPI с IP-KVM.
Да я как бы в курсе за всякие iLO, IMM2. Но в те времена когда я вывел это правило — у меня не было таких серверов
Я никогда не буду делать /etc/init.d/iptables на удаленном сервере :)
а что мешает это делать в скрине? ;)
У меня похожие проблемы (не race condition, но всё же) были c 6to4 на селектеловском облаке.

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

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

Решил поднятием 6to4 интерфейса отдельным init скриптом вместо auto в /etc/network/interfaces.
Да, я знаю об этой проблеме (она же так же затрагивает модули нестандартных ФС, таких, как xfs/jfs) — их нужно монтировать в rc.local.
А мне было интересно посмотреть на получившийся mindmap у решения (хотя наверное я слишком многого прошу)
а ещё можно послать багрепорт и решить эту проблему самым правильным методом — устранить проблему. При этом, чем лучше (и по сути) вы опишете проблему, тем больше вероятность, что её решат

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

Расскажите, что именно у меня выступает в роли микроскопа.
очевидно же, что речь идет о монтировании nfs через fstab
Я и в lenny ловил проблемы с заторможенностью hotplug. С тех пор после инсталляции первыми делом выпиливаю hotplug и ставлю обычный auto eth0.
Хорошая, весьма интересная статья. Спасибо.
я даже не сисадмин, а убунту-юзер, но под пиво прочиталось на одном дыхании. спасибо.
Sign up to leave a comment.

Articles