O comando ping do Linux sai cedo devido a um host ICMP inacessível

Question

Um script automatizado executa shutdown -r now em uma máquina e, após um atraso de 30s, usa ping para determinar quando a máquina está disponível. Eu mudei recentemente o sistema operacional do Centos 5 para o Oracle Linux 6 e descobri que o comportamento do ping mudou.

Eu uso o ping com a contagem (-c10), o prazo (-w360) e o atraso (-W1), que devem esperar até cinco minutos por dez respostas bem-sucedidas da máquina.

Eu observo minha própria máquina gerando Destination Host Unreachable mensagens após 30 segundos que fazem com que ping seja encerrado após 3 erros, por exemplo. bem antes do meu valor de prazo desejado. Por exemplo. exemplo saindo após ~ 37 segundos:

[cs@bst1 ~]# time ping -c10 -w360 -W1 hostother; echo $?
PING hostother (10.210.51.155) 56(84) bytes of data.
From bst1 (10.210.51.139) icmp_seq=36 Destination Host Unreachable
From bst1 (10.210.51.139) icmp_seq=37 Destination Host Unreachable
From bst1 (10.210.51.139) icmp_seq=38 Destination Host Unreachable

--- hostother ping statistics ---
38 packets transmitted, 0 received, +3 errors, 100% packet loss, time 37008ms
pipe 3

real    0m37.010s
user    0m0.001s
sys     0m0.000s
1

Isso parece entrar em conflito com man ping :

If ping does not receive any reply packets at all it will exit with code 1. If a packet count and deadline are both specified, and fewer than count packets are received by the time the deadline has arrived, it will also exit with code 1. On other error it exits with code 2. Otherwise it exits with code 0. This makes it possible to use the exit code to see if a host is alive or not.

1) O comportamento do ping em relação aos erros do ICMP é consistente com a página man? Parece que o código de retorno deve ser 2 sob condições de erro.

2) É possível impedir que minha máquina entre com essas mensagens Destination Host Unreachable ?

Se eu executar novamente o ping algumas vezes, ele eventualmente verá o host e sairá limpo (código de retorno 0).

    

Answer 1

Sugiro que você limpe o tempo limite do ping e use o comando timeout (parte do coreutils):

timeout 300s bash -c "until ping -c10 hostother; do false; done"

Você receberá 124 como código de retorno se o comando expirar; por exemplo. se não conseguir 10 pings consecutivos em 5 minutos, e 0 se o ping for bem sucedido, assim que acontecer.

Eu sei que isso não realmente responde à pergunta (admito que a página ping man não é clara), mas que, espera-se, resolva seu problema imediato.

    

Answer 2

1) Sim, o comportamento do PING é consistente. "Host de destino inacessível" pode significar várias coisas, mas uma delas é " este host tem um endereço que indica que está na minha LAN, mas não responde a solicitações ARP e não tenho uma entrada de cache ARP válida para isso ".

Aqui está eu PINGando algo na minha LAN e mostrando que não tem entrada de cache ARP:

[me@risby]$ ping 192.168.3.244
PING 192.168.3.244 (192.168.3.244) 56(84) bytes of data.
From 192.168.3.11 icmp_seq=1 Destination Host Unreachable
From 192.168.3.11 icmp_seq=2 Destination Host Unreachable
From 192.168.3.11 icmp_seq=3 Destination Host Unreachable
[...]
[me@risby]$ arp -a -n|grep 244
? (192.168.3.244) at <incomplete> on p1p1

O PING não está produzindo o erro 2 porque é verdade que nenhum pacote de resposta foi recebido. Também é verdade que este não é o problema do PING; ele pediu ao kernel para enviar icmp-echo-requests, e o kernel indicou que não pode fazer isso. Aqui está um exemplo de erro 2, ou seja, " eu, PING, simplesmente não consigo executar essas instruções; deixei cair a bola ":

[me@risby]$ ping -c 3 192.168.3.999
ping: unknown host 192.168.3.999
[me@risby]$ echo $?
2

2) Não.

Como outros já sugeriram, você escolheu o caminho errado para testar um host que está inativo, ao contrário do ICMP-echo-request-não-responsivo.