Eu tive o mesmo problema aqui no Debian Testing com o Kernel 3.12.XXX. Para mim o comando setarch (ou linux64) funcionou:
web3:~# setarch x86_64 --uname-2.6 tw_cli /c0/u0 show all
ou
web3:~# linux64 --uname-2.6 tw_cli /c0/u0 show all
Eu já notifiquei o suporte do LSI duas vezes, mas até agora eles não conseguiram reproduzir o problema. Eu queria postar aqui para ter alguns pensamentos imparciais sobre isso e ver se alguém já viu um problema semelhante.
Gerenciamos vários servidores que fornecem serviços de Internet com IO de disco muito pesado. Todos executam testes Debian (Sid) -amd64 e usam placas RAID 3ware da série 85xx-96xx. Com as atualizações do kernel do Debian para 3.9.x-amd64, começamos a obter um segfault com o tw_cli. Testamos tdm2 e também segfaults.
Para reproduzir o problema: (Você não precisa de uma placa RAID no seu sistema para fazer isso) 1. Nova instalação do teste Debian (Sid). O ISO é link 2. Instale o tw_cli e tente executá-lo.
Nós rodamos tw_cli como root com strace abaixo de 3.2 e 3.9.6 / 3.9.8-amd64 e o segfault está acontecendo logo após o tw_cli chamar o uname, como você pode ver abaixo.
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) ---
Na boa execução acima, a próxima chamada após o uname é abrir / proc / devices que existem e não devem ser um problema. Algo mais que achamos que é notável e você pode vê-lo na má execução acima, uname no kernel 3.9 / 3.10 adiciona uma data à string.
Achamos que essas duas execuções de strace podem indicar que o tw_cli está falhando porque está obtendo uma resposta inesperada da chamada uname. O suporte do LSI diz:
"3dm2 e tw_cli funcionam bem, mesmo com os últimos kernels do Ubuntu 3.10.xe o Ubuntu geralmente extrai kernels instáveis do Debian e os usa para seus lançamentos."
FWIW, não sei ao certo o que o suporte do LSI está falando. Acabamos de testar com uma nova e atualizada instalação do Ubuntu 1304 (Raring Ringtail) e uname -a mostra "Linux mac-workstation 3.8.0-26-genérico # 38-Ubuntu SMP seg Jun 17 21:43:33 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux ". Então o Ubuntu 1304 está usando o kernel 3.8, não 3.10. E tw_cli & tdm2 ambos funcionam bem.
Então, qualquer pensamento útil? No momento, nossas opções parecem ser: - fixe a versão do kernel em 3.2 e espere que o problema seja corrigido em breve - Pare de monitorar nossos RAIDs (não é realmente uma opção) - compilar kernels personalizados para todos os nossos servidores, porque aparentemente o kernel do Debian Testing tem esse problema - mude para o Ubuntu para todos os nossos servidores (não é viável) - mudar nossos cartões RAID para alguém como o Areca (também não é viável para servidores existentes, mas está sendo considerado para a próxima geração de servidores)
=================== acompanhamento =========================== =
Acabei de receber a seguinte resposta do suporte do LSI / 3ware. Receio que a minha resposta a eles não tenha sido muito boa, embora acredite que resumiu a situação com precisão.
O LSI / 3ware disse: Nós somos capazes de reproduzir o problema com o kernel instável do Debian 3.9-1-amd64, mas a engenharia não libera o software para kernels não estáveis ou liberados. Se possível, aguarde até que o Debian libere oficialmente o kernel. O 3dm2 e o tw_cli devem funcionar com o lançamento oficial do Ubuntu 13.04, incluindo os kernels atualizados 3.8.x a 3.10.
Minha resposta:
Então o resultado final é:
Em vez disso, você primeiro compila um kernel personalizado que de alguma forma evita o problema. Então você pula OVER Testing para Unstable para reproduzir o problema. Exceto "engenharia não libera software para kernels não estáveis ou não liberados" ... então mais uma vez você evita ter que tomar qualquer ação.
A boa notícia para nós é que estamos na comunidade Debian e vamos deixar todos saberem como isso foi tratado pelo LSI. Isso vai enviar um sinal strong ao resto da comunidade Linux sobre a viabilidade a longo prazo de seus produtos.
Obrigado
============= minha conclusão =============
Sim, nós usamos o lançamento oficial do Debian Testing em produção e alguns acham que não é sábio.
No entanto, debater isso não resolve o problema, e eventualmente o kernel do Testing entra no Stable. E o tempo para qualquer fabricante consertar seu software proprietário que é essencial para o uso de seu produto é com a distribuição do Teste ... ANTES de chegar ao Estável.
Então, enquanto esperamos que o LSI / 3ware decida carregar o Debian Testing oficial e consertar seu software, nós provavelmente colocaremos o kernel em 3.2. Também podemos encontrar tempo para compilar um kernel 3.10 que não produza uma data com uname -r para ver se essa é realmente a causa. Se for, podemos conseguir que isso seja alterado na chamada uname do kernel.
Eu tive o mesmo problema aqui no Debian Testing com o Kernel 3.12.XXX. Para mim o comando setarch (ou linux64) funcionou:
web3:~# setarch x86_64 --uname-2.6 tw_cli /c0/u0 show all
ou
web3:~# linux64 --uname-2.6 tw_cli /c0/u0 show all
O problema não é a data, é que tw_cli está procurando por XYZ (-R-arch) na versão e está apenas obtendo XY (-R-arch) - 3.2.0-4-amd64 vs 3.10-2 -amd64. Quando o release é definido como 3.10.0-2-amd64, ele é executado corretamente. Eles podem estar fazendo um sscanf () com formatos limitados e pouca ou nenhuma verificação de erros.
jam:~# uname -r 3.10-2-amd64 jam:~# tw_cli /c0 show firmware Segmentation fault jam:~# echo 3.10.0-2-amd64 > /sys/module/utsname/parameters/release jam:~# uname -r 3.10.0-2-amd64 jam:~# tw_cli /c0 show firmware /c0 Firmware Version = FE9X 4.10.00.027
Se o binário era dinâmico, você poderia ver sobre uma substituição uname () com LD_PRELOAD, mas é estático. Não há código-fonte, por isso nossas opções são limitadas:
Eu gosto do meu 9650, mas isso é uma porcaria.
Você não deve executar o teste Debian a menos que você queira testá-lo. Especialmente não em um servidor. Eu diria que tente reproduzi-lo no Debian estável.
Além disso, os cartões LSI 3ware vêm com uma excelente interface de administração baseada na web que permite configurá-lo para enviar alertas. Nesse caso, você não precisa usar o tw_cli em um script para enviar esses alertas por e-mail e, assim, evitar o problema que você está tendo.
Na verdade, pense nisso, se tdm2 segfaults, então a interface administrativa também não está funcionando ...
Tenha o mesmo problema no teste Debian com o kernel 3.10 (incluindo o tw_cli segfault). Precisa mencionar, o teste Debian é muito mais estável que outras distros chamadas 'stable releases';) No entanto, parece que existe um problema relacionado à versão do kernel mais do que testar a distro. Voltou para o 3.2 e funciona bem, também esperando pela atualização do software LSI, mas temos 3ware 9500 series, então não há grandes esperanças para isso.