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

Мы управляем рядом серверов, которые предоставляют Интернет-услуги с очень тяжелым дисковым вводом-выводом. Все запускают Debian testing (Sid) -amd64 и используют карты RAID 3ware серий 85xx - 96xx. С обновлением ядра Debian до 3.9.x-amd64 мы начали получать segfault с tw_cli. Мы протестировали tdm2, и он тоже не работает.

Чтобы воспроизвести проблему: (Для этого вам не нужна карта RAID в вашей системе) 1. Свежая установка Debian для тестирования (Sid). ISO http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/ 2. Установите tw_cli и попробуйте его запустить.

Мы запустили tw_cli как root со strace под 3.2 и 3.9.6 / 3.9.8-amd64, и segfault происходит сразу после того, как tw_cli вызывает uname, как вы можете видеть ниже.

Хорошая работа:

execve("/usr/local/sbin/tw_cli", ["tw_cli", "/c0", "show", "all"], ["TERM=xterm", "SHELL=/bin/bash", "SSH_CLIENT=71.207.183.174 60609 "..., "SSH_TTY=/dev/pts/0", "USER=root", "MAIL=/var/mail/root", "PATH=/usr/local/sbin:/usr/local/"..., "PWD=/root", "LANG=C", "PS1=\\h:\\w\\$ ", "SHLVL=1", "HOME=/root", "LOGNAME=root", "SSH_CONNECTION=71.207.183.174 60"..., "_=/usr/bin/strace"]) = 0
uname({sysname="Linux", nodename="yorick.ironicdesign.com", release="3.2.0-4-amd64", version="#1 SMP Debian 3.2.46-1", machine="x86_64"}) = 0
brk(0)                                  = 0x2664000
brk(0x2685000)                          = 0x2685000
uname({sysname="Linux", nodename="yorick.ironicdesign.com", release="3.2.0-4-amd64", version="#1 SMP Debian 3.2.46-1", machine="x86_64"}) = 0
open("/proc/devices", O_RDONLY)         = 3
...

Плохой ход:

execve("/usr/local/sbin/tw_cli", ["tw_cli", "/c0", "show", "all"], ["SHELL=/bin/bash", "TERM=screen", "SSH_CLIENT=98.26.9.112 58271 22", "SSH_TTY=/dev/pts/0", "USER=root", "SSH_AUTH_SOCK=/tmp/ssh-595iwzIik"..., "TERMCAP=SC|screen|VT 100/ANSI X3"..., "PATH=/usr/local/sbin:/usr/local/"..., "MAIL=/var/mail/root", "STY=17473.mdorman", "PWD=/root", "LANG=C", "PS1=\\h:\\w\\$ ", "HOME=/root", "SHLVL=2", "LOGNAME=root", "WINDOW=0", "SSH_CONNECTION=98.26.9.112 58271"..., "_=/usr/bin/strace"]) = 0
uname({sysname="Linux", nodename="yorick.ironicdesign.com", release="3.10-1-amd64", version="#1 SMP Debian 3.10.1-1 (2013-07-16)", machine="x86_64"}) = 0
brk(0)                                  = 0x26ef000
brk(0x2710000)                          = 0x2710000
uname({sysname="Linux", nodename="yorick.ironicdesign.com", release="3.10-1-amd64", version="#1 SMP Debian 3.10.1-1 (2013-07-16)", machine="x86_64"}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---

В приведенном выше примере следующий вызов после uname - открыть / proc / devices, который ДЕЙСТВИТЕЛЬНО существует и не должен быть проблемой. Есть еще кое-что, что мы считаем примечательным, и вы можете увидеть это в приведенном выше неудачном прогоне, uname в ядре 3.9 / 3.10 добавляет дату в строку.

Мы думаем, что эти два запуска strace могут указывать на сбой tw_cli из-за получения неожиданного ответа от вызова uname. Служба поддержки LSI сообщает:

«3dm2 и tw_cli отлично работают даже с последними ядрами Ubuntu 3.10.x, а Ubuntu обычно извлекает нестабильные ядра из Debian и использует их для своих выпусков».

FWIW, я не уверен, о чем говорит поддержка LSI. Мы только что протестировали свежую, актуальную установку Ubuntu 1304 (Raring Ringtail), а uname -a показывает «Linux mac-workstation 3.8.0-26-generic # 38-Ubuntu SMP Mon Jun 17 21:43:33 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux ". Итак, Ubuntu 1304 использует ядро ​​3.8, а не 3.10. И tw_cli & tdm2 работают нормально.

Итак, какие-нибудь полезные мысли? На данный момент у нас есть следующие варианты: - закрепить нашу версию ядра на 3.2 и надеяться, что проблема скоро будет исправлена ​​- прекратить мониторинг наших RAID (на самом деле не вариант) - скомпилировать пользовательские ядра для всех наших серверов, потому что, очевидно, стандартное тестирование Debian У ядра есть эта проблема - переключитесь на Ubuntu для всех наших серверов (невозможно) - переключите наши карты RAID на кого-то вроде Areca (также невозможно для существующих серверов, но рассматривается для нашего следующего поколения серверов)

=================== продолжение ============================

Я только что получил следующий ответ от службы поддержки LSI / 3ware. Боюсь, мой ответ на них был не очень приятным, хотя я считаю, что он точно описал ситуацию.

LSI / 3ware заявила: «Мы можем воспроизвести проблему с нестабильным ядром Debian 3.9-1-amd64, но инженеры не выпускают программное обеспечение для нестабильных или невыпущенных ядер. Если возможно, подождите, пока Debian официально выпустит ядро. 3dm2 и tw_cli должны работать с официальным выпуском Ubuntu 13.04, включая обновленные ядра с 3.8.x до 3.10.

Мой ответ:

Итак, конечный результат:

• Вы не будете выполнять новую установку Debian Testing, чтобы воспроизвести проблему. Я даже дал вам ссылку на "Официальный" тестовый ISO, в котором ДЕЙСТВИТЕЛЬНО есть проблема.

Вместо этого вы сначала компилируете собственное ядро, которое каким-то образом позволяет избежать проблемы. Затем вы перескакиваете ОТ Testing к Unstable, чтобы воспроизвести проблему. За исключением того, что «разработка не выпускает программное обеспечение для нестабильных или невыпущенных ядер» ... так что вам еще раз не нужно предпринимать никаких действий.

• Тогда у вас хватит смелости предложить, чтобы мы не использовали официальный выпуск Debian (мы ЕСТЬ) ИЛИ что мы можем просто закрыть наши службы, работающие на всех наших серверах, и переключиться на новый дистрибутив ???

Хорошая новость для нас заключается в том, что мы в сообществе Debian и расскажем всем, как с этим справилась LSI. Это станет СИЛЬНЫМ сигналом для остальной части сообщества Linux о долгосрочной жизнеспособности ваших продуктов.

Спасибо

============= мой вывод =============

Да, мы ДЕЙСТВИТЕЛЬНО используем официальный тестовый выпуск Debian в производственной среде, и некоторые думают, что это неразумно.

Однако споры, которые здесь не решают проблему, что в конечном итоге ядро ​​из Testing переходит в стабильную версию. И любому производителю пора исправить свое проприетарное программное обеспечение, необходимое для использования его продукта, - это тестовый дистрибутив ... ДО того, как он попадет в стабильную версию.

Итак, пока мы ждем, пока LSI / 3ware решит загрузить официальное тестирование Debian и исправить свое программное обеспечение, мы, вероятно, закрепим наше ядро ​​на версии 3.2. Мы также можем найти время для компиляции ядра 3.10, которое не выводит дату с uname -r, чтобы увидеть, действительно ли это является причиной. Если это так, мы сможем изменить это в вызове uname для ядра.