Какой процесс Linux отвечает за ответы на эхо-запросы?

Вы можете создать ассоциативный массив в качестве таблицы поиска для дополнений, например

awk '
  BEGIN {
    complement["A"]="T"; complement["T"]="A";
    complement["C"]="G"; complement["G"]="C";
  } 

  NR>1 && $3!=$2 && $4!=$2 {
    $3 = complement[$3]; 
    $4 = complement[$4];
  } 

  {
    print;
  }
' file
39
25.04.2018, 03:39
3 ответа

Нет пользовательского процесса, отвечающего за эхо-запросы. Ping — это просто утилита для отправки эхо-пакетов ICMP. Они принимаются и обрабатываются сетевым стеком ядра

.
12
27.01.2020, 19:35

Сетевой стек ядра обрабатывает сообщения ICMP, отправляемые командой ping.

Если вы не получаете ответов, помимо проблем с сетью или фильтрацией, а также фильтрации/ограничения скорости -/черного -дырирования/и т. д. это означает, что машина, вероятно, чем-то перегружена, что может быть временным, или произошел сбой ядра, что бывает редко, но может случиться (неисправное оборудование и т. д. ), не обязательно из-за трафика ICMP (, но попытка перегрузить его таким трафиком может быть хорошей проверкой в ​​начале жизни сервера, чтобы увидеть, как он поддерживает вещи ). В более позднем случае сбоя ядра у вас должно быть достаточно информации в файлах журнала или на консоли.

Также обратите внимание, что pingпочти всегда является неправильным инструментом для проверки того, находится ли служба в сети или нет. По разным причинам, но в основном потому, что он по определению не имитирует реальный трафик приложения. Например, если вам нужно проверить, что веб-сервер все еще работает, вы должны вместо этого сделать HTTP-запрос к нему (TCP-порт 80 или 443 ), если вам нужно проверить почтовый сервер, вы делаете SMTP-запрос (TCP-порт 25 ), если DNS-сервер, UDP и TCP-запрос к порту 53 и т. д.

58
27.01.2020, 19:35

Само ядро ​​(, а не какой-либо пользовательский процесс ), отвечает за отправку сообщений эхо-ответа ICMP в ответ на сообщения эхо-запроса ICMP . Итак, если хост перестает отвечать на эхо-запросы, это обычно происходит по одной из следующих причин:

  • сетевое соединение между вами и проверяемым хостом могло быть прервано. Это может быть связано с массой причин :: физическим повреждением кабелей, помехами в беспроводной сети, неработающими таблицами маршрутизации, DDoS-атакой, проблемными маршрутизаторами/переключателями и т. д. В этом случае вы должны начать устранение неполадок, используя ethtool(8), iwconfig(8), route(8), ping(8)его маршрутизатор, tcpdump(8)и т. д. на целевом хосте.

  • Настройка брандмауэра на целевом хосте (или любом маршрутизаторе/брандмауэре между вами и целевым хостом )может ограничивать количество пингов (или объем трафика ). Это также может быть связано с такими инструментами, как fail2ban(8)брандмауэр по запросу. См. iptables(8)для проверки.

  • На целевом хосте произошел сбой программного/аппаратного обеспечения. Сетевой модуль ядра на целевом хосте мог выйти из строя и/или запутаться, или даже все ядро ​​могло запаниковать. Вы увидите сообщения об этом в dmesg(8)на целевом хосте или в виде вывода на экран на физической консоли (, если физический доступ нецелесообразен, может помочь другая машина с последовательной консолью . )Если проблема в ядре OOPS/PANIC, может помочь более новое ядро ​​с лучшими драйверами, или вы можете обойти системные зависания с помощью watchdog(8)и вспомогательных драйверов. Или вы можете изменить аппаратные части.

11
27.01.2020, 19:35

Теги

Похожие вопросы