Por que 'pkill /?' matar minha sessão SSH?

5

Depois de executar os seguintes comandos (bash) como root via SSH:

    pkill --help
    pkill -h
    pkill /?

Os dois primeiros comandos não me deram nenhuma informação, por isso corri o terceiro (meio instintivamente ...).

O que aconteceu depois é que a minha sessão SSH para o servidor foi fechada e não se reconectou. Eu estou supondo que parou todos (ou a maioria) dos processos em execução, incluindo o daemon responsável por tais sessões.

Eu gostaria de entender por que isso aconteceu: Qual é a avaliação exata (passo-a-passo) de minha entrada e o que ela causou?

Meu melhor palpite é que isso tem algo a ver com a avaliação do shell de '?' caractere, que provavelmente traduziu para uma lista de algumas expressões de caractere único que foram passadas para pkill, que por sua vez, fechou esses PIDs.

    
por scooz 12.07.2012 / 16:17

3 respostas

20

No CentOS 5.2, a página man fornecida executando man pkill diz que interpretaria o /? como uma expressão regular estendida para nomes de processos ou linhas de comando.

Então o? significa que o personagem anterior pode ou não aparecer. Como havia apenas um outro caractere, o /, então o pkill matou todos os processos possíveis.

Nos sistemas Linux, tente lembrar o comando man para obter a documentação primeiro.

    
por 12.07.2012 / 16:26
7

Executar pgrep /? ...

Isso retornará os PIDs dos processos correspondentes a esse padrão de shell. A execução de pkill com o mesmo parâmetro eliminará tudo listado na saída pgrep /? .

Eu acho que você estava matando sua própria sessão, assim como vários outros processos (todos os PIDs, neste caso).

    
por 12.07.2012 / 16:26
3

A sintaxe das expressões de linha de comando de /switch1 /switch2 é uma coisa do Windows / DOS. No Linux e em todos os UNIXs que conheço, a sintaxe do argumento da linha de comandos é --switch -s . /? está sendo considerado como uma expressão regular. A expressão regular /? , pelo menos tanto quanto eu posso dizer da página man grep , corresponderia a 0 ou 1 / es. Isso não parece explicar por que isso mataria o SSH, mas explica o que aconteceu.

    
por 12.07.2012 / 16:50