Автоматический скрипт запускается shutdown -r now на машине и после 30-секундной задержки использует команду ping, чтобы определить, когда машина доступна. Недавно я переключил ОС с Centos 5 на Oracle Linux 6 и обнаружил, что поведение ping изменилось.
Я использую команду ping с подсчетом (-c10), крайним сроком (-w360) и задержкой (-W1), которые должны ждать до пяти минут для десяти успешных ответов с машины.
Я наблюдаю, как моя собственная машина генерирует Destination Host Unreachable сообщения через 30 секунд, которые вызывают ping для выхода после 3 ошибок т.е. задолго до желаемого срока сдачи. Например. пример выхода через ~ 37 секунд:
[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
Кажется, это противоречит man ping:
Если ping вообще не получает никаких ответных пакетов, он выйдет с кодом 1. Если количество пакетов и крайний срок указаны и меньше, чем количество пакетов получено к моменту наступления крайнего срока, он также выйдет с кодом 1. При другой ошибке он выходит с кодом 2. В противном случае он выходит с кодом 0. Это позволяет использовать код выхода, чтобы узнать, жив ли хост или нет.
1) Согласуется ли поведение ping перед ошибками ICMP со страницей руководства? Кажется, что код возврата должен быть 2 в условиях ошибки.
2) Можно ли запретить моей машине прыгать с этими Destination Host Unreachable Сообщения?
Если я перезапущу команду ping несколько раз, она в конечном итоге обнаружит хост и завершит работу (код возврата 0).
Я предлагаю вам увеличить время ожидания от ping и использовать timeout вместо этого команда (часть coreutils):
timeout 300s bash -c "until ping -c10 hostother; do false; done"
Ты получишь 124 как код возврата, если истекло время ожидания команды; например если ему не удалось выполнить 10 последовательных эхо-запросов за 5 минут, и 0 если ping удалось, как только это произойдет.
Я знаю, что это не так действительно ответь на вопрос (признаю ping страница руководства не совсем ясна), но, надеюсь, решит вашу непосредственную проблему.
1) Да, поведение PING согласовано. "Целевой хост недоступен" может означать несколько вещей, но одно из них - "у этого хоста есть адрес, который указывает, что он находится в моей локальной сети, но он не отвечает на запросы ARP, и у меня нет действительной записи в кэше ARP для него".
Вот я что-то пингую в своей локальной сети и показываю, что в нем нет записи кэша 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
PING не вызывает ошибку 2, потому что ответные пакеты не принимаются. Также верно, что это не проблема PING; он попросил ядро отправить эхо-запросы icmp, и ядро сообщило, что оно не может этого сделать. Вот пример ошибки 2, т. Е. "Я, PING, просто не могу выполнить эти инструкции; Я уронил мяч":
[me@risby]$ ping -c 3 192.168.3.999
ping: unknown host 192.168.3.999
[me@risby]$ echo $?
2
2) Нет.
Как отмечали другие, вы выбрали неправильный способ проверки того, что хост не работает, в отличие от ICMP-echo-request-unresponsive.