LINUX.ORG.RU
решено ФорумAdmin

Не поднимается FCoE после обновления в RHEL 7.6

 , , ,


1

0

После обновления с RHEL 7.5 до RHEL 7.6 при загрузке перестали подниматься оба интерфейса FCoE.
Поднимается только один интерфейс и диски доступны только по половине путей.
Один раз особо «удачно» удалось загрузиться так, что не поднялись оба интерфейса - соответственно диски не были доступны вообще.
Если вручную сделать «ifdown eno3» / «ifup eno3», то поднимается, а вот при загрузке - фиг.

Явно какой-то рэйс.
Если при загрузке выбрать в меню GRUB2 предыдущее ядро (от RHEL 7.5), то всегда поднимаются оба интерфейса.

Железо - HP ProLiant BL460c Gen10 с конвергентным HBA 630FLB.

Ладно, чего голову ломать, если есть отличная поддержка RedHat? Завел кейс.

Техподдержка предложила добавить 2 строчки в файл /lib/systemd/system/fcoe.service:


[Unit]
Description=Open-FCoE Inititator.
After=syslog.target network.target lldpad.service

[Service]
Type=forking
EnvironmentFile=/etc/sysconfig/fcoe
ExecStartPre=/sbin/modprobe -qa $SUPPORTED_DRIVERS
ExecStart=/usr/sbin/fcoemon $FCOEMON_OPTS
Type=oneshot                                           <---- Added
ExecStart=/usr/sbin/fipvlan -acds                      <---- Added

[Install]
WantedBy=multi-user.target

Я очень удивился. Осторожно спросил - а уверен ли он, что сервис может быть одновременно и Type=forking и Type=oneshot?
Мало ли, бывает, опечатался человек.
На что он ответил - да, первый ExecStart запустится как forking, а второй - как oneshot. А вообще, говорит, «мопед не мой, мы это советовали другому клиенту, у которого была аналогичная проблема. Правда, он после этого к нам не вернулся и мы не знаем, помогло ли это ему.»

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

Вопрос про systemd - а что, так можно - указывать несколько Type= в сервисе?

Самое интересно, что оба ExecStart действительно отрабатывают, правда, демон /usr/sbin/fcoemon, указанный в первом ExecStart, на «нормальной» системе стартует при загрузке и постоянно запущен, а после этих модификаций он сразу же завершается. На вопрос RedHat'у «а нормально ли это», индусы ушли в астрал (видимо на следующий уровень поддержки), после чего в треде появился единственный вменяемый чувак, который сказал «включи дебаг fcoe и собери логи. И убери все эти изменения».

Так вот - это что, штатная фича systemd и это применяется? Я не нашел, чтобы это было документировано. Да выглядит как-то криво.

Короче - это и правда полная хрень или наоборот совет от мега-хакеров systemd?

★★★★★

Последнее исправление: bigbit (всего исправлений: 1)

Правда, он после этого к нам не вернулся

Didnt get back to us значит не отписался

mos ★★☆☆☆
()

Техподдержка предложила добавить 2 строчки в файл /lib/systemd/system/fcoe.service

Техподдержка

добавить ... в файл .service

Обычно это через systemctl edit делается, чтобы при обновлении изменения не потерять.

After=syslog.target network.target lldpad.service

Есть подозрение, что тут должно быть еще network-online.target, но этот таргет зависит от того, чем сеть рулится.

Ну так с моего дивана видно.

Radjah ★★★★★
()
Последнее исправление: Radjah (всего исправлений: 1)

это дичь. читается конфиг, последнее из одинаковых вхождений исполняется

SevikL ★★★★★
()
Ответ на: комментарий от intelfx

Вопрос про systemd - а что, так можно - указывать несколько Type= в сервисе?

Нет, это лажа.

Тогда почему это молча воспринимается?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Я, возможно, неточно выразился. Лажа в том, что это не будет работать так, как сказал саппорт. А вообще это допустимо и вторая директива перезапишет первую.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Я тебе даже скажу, зачем это сделано. Есть такая вещь, как Drop-In файлы, которые кладутся в /etc/systemd/system/<имя_юнита>.d, в них можно переопределять некоторые переменные юнита, в том числе Type, не копируя весь файл юнита в /etc.

eternal_sorrow ★★★★★
()
Последнее исправление: eternal_sorrow (всего исправлений: 1)
Ответ на: комментарий от eternal_sorrow

Я тебе даже скажу, зачем это сделано

Пока не сказал.

Есть такая вещь, как Drop-In файлы

Пока что речь шла о двух указаниях Type в одном файле. Впрочем, переопределние в drop-in тоже отличная идея. Так очевидно.

tailgunner ★★★★★
()
Ответ на: комментарий от eternal_sorrow

В одном - это явная лажа. В разных - просто кривое проектирование (имеется в виду кривое проектирование формата юнитов).

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Если ты не заметил, я назвал тебе формальную причину, по которой повторное присваивание per se — это не «лажа». Она проста: это намеренное поведение. Я тебе ничего не доказываю и не «оправдываю».

intelfx ★★★★★
()
Ответ на: комментарий от tailgunner

Подозреваю, что тут дело не в линтерах, а в архитектуре. У systemctl есть команда edit. Позволяет добавлять изменения в unit-файл, не меняя оригинал. Если я правильно понимаю, реализовано это таким образом, что всё, что ты понапишешь в systemctl edit, при сборке цельного Unit'а добавляется в конец оригинала.

Но на шоколадку не поспорю.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Подозреваю, что тут дело не в линтерах, а в архитектуре

То, что в архитектуре systemd не нашлось места (AFAIK) валидации и линтерам - это как раз и печально. Была же возможность сделать нормально.

Напоминает скрипты на XML, только вместо XML - ini-файл.

всё, что ты понапишешь в systemctl edit, при сборке цельного Unit'а добавляется в конец оригинала.

Если так, то это еще одно блестящее техническое решение.

tailgunner ★★★★★
()
Ответ на: комментарий от post-factum

Ушёл читать тикет.

Насколько я понимаю, FCoE конфликтует с бондингом.
Там всего 4 интерфейса:
eno1 и eno2 - обычные сетевые интерфейсы
eno3 и eno4 - FCoE

После того, как появляется линк на сетевых интерфейсах, из eno1 и eno2 собирается бондинг, а на eno3 и eno4 запускаются инициаторы. И все это происходит одновременно.
А когда поднимается бондинг, он почему-то сначала кратковременно кладет сетевой интерфейс (в логах видны сообщения eno1 is definitely down, disabling interface), а спустя секунду поднимает его. Поскольку это конвергентная карточка, то если положить eno1, то eno3 тоже ляжет (не могу сейчас сделать тест, но, насколько я помню, это так). И вот это кратковременное опускание eno1 происходит именно в тот момент, когда пытается запуститься FCoE на eno3 и eno4 - и это на него плохо влияет.

Если сравнивать с логами RHEL 7.5, там бондинг поднимается перед FCoE, и все работает. А в 7.6 и бондинг и FCoE запускаются одновременно.

bigbit ★★★★★
() автор топика
Ответ на: комментарий от post-factum

Одна из последних записей - что RedHat обнаружили зависимость от бондинга и активно работают.
Эту мысль я не писал - если девелоперы работают, то куда мне-то лезть :)

bigbit ★★★★★
() автор топика
Последнее исправление: bigbit (всего исправлений: 1)
Ответ на: комментарий от bigbit

Ну как бы процесс двусторонний, вдруг натолкнёшь их на более правильные мысли.

post-factum ★★★★★
()
Ответ на: комментарий от tailgunner

Честно говоря, подробное поведение («перезапись» параметров «или кто последний тот и отец») свойственно не только systemd. Хорошо это ли плохо сложно сказать, но в данном случае скорее «плохо» что нет как минимум предупреждения о том что параметр перезаписан.

anc ★★★★★
()
30 апреля 2019 г.

Свершилось!
Сегодня пришло обновление по кейсу, что выпустили патч: RHBA-2019:0515

Итого:
- месяц на продирание сквозь техподдержку и воспроизведние проблемы на стороне RedHat
- месяц на написание патча (тестовый пакет fcoe-utils, решающий проблему, мне дали в январе, только сказали не использовать в продакшене)
- 3 месяца на выпуск официального патча

В целом неплохо.

Практически одновременно с этим кейсом завел другой кейс - если вручную запустить команду fcoemon, то все LUN'ы отрубаются нахрен.
Конечно, fcoemon в здравом уме не нужно запускать вручную, но команда находится в путях, и по ошибке (или по незнанию) можно это сделать. Не должен простой запуск с виду безобидной команды приводить к таким катастрофическим последствиям.
С этим кейсом пока глухо. Прямо бета-тестером себя ощущаю.

bigbit ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.