Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
I have a Linux based process controller that occasionally locks up to the point where you can't ping it (i.e. I can ping it, then it becomes no longer pingable without any modifications to network settings).
I'm curious, what process/system is responsible for actually responding to pings? It appears that this process is crashing.
The kernel network stack is handling ICMP messages, which are those sent by the ping command.
If you do not get replies, besides network problems or filtering, and host based filtering/rate-limiting/black-holing/etc. it means the machine is probably overloaded by something, which can be transient, or the kernel crashed, which is rare but can happen (faulty hardware, etc.), not necessarily because of the ICMP traffic (but trying to overload it with such traffic can be a good test at the beginning of life of a server to see how it sustains things). In the later case of kernel crash you should have ample information in the log files or on the console.
Also note that ping is almost always the wrong tool to check if a service is online or not. For various reasons, but mostly because it does not mimic real application traffic, by definition.
For example if you need to check that a webserver is still live, you should instead do an HTTP query to it (TCP port 80 or 443), if you need to check a mailserver you do an SMTP query (TCP port 25), if a DNS server, an UDP and a TCP query to port 53, etc.
ping as this creates far too many false positive in troubleshooting so I think users not knowing exactly what ping does and how it can gives misleading results should stick to something else.
Apr 24, 2018 at 17:35
There is no userland process responsible for responding to pings. Ping is just a utility to send ICMP echo packets. These are received and process by the kernel's networking stack
The kernel itself (not any user process) is responsible to sending ICMP echo reply messages in response to ICMP echo request messages. So, if a host stops responding to pings, it is usually due to some of the following reasons:
network connectivity between you and host being pinged might have been severed.
It could be due to tons of reasons itself: physical damage to the cables, noise in the case of wireless, broken route tables, you being under DDoS attack, problematic routers/switches in between etc.
You'd start troubleshooting in this case by using ethtool(8), iwconfig(8), route(8), ping(8) its router, tcpdump(8) etc. on target host.
firewall setting on target host (or any router/firewall in between you and target host) may be limiting amount of pings (or amount of traffic traffic). It could also be due to tools like fail2ban(8) firewalling stuff on demand. See iptables(8) to check.
there has been software/hardware malfunction at target host. Network kernel module on target host might have OOPSed and/or become confused, or even whole kernel might have PANICked. You'll see messages about at in dmesg(8) on target host, or as screen output on physical console (if physical access is impractical, another machine with serial console can help.) If kernel OOPS/PANIC is the problem, newer kernel with better drivers might help, or you could kludge around the system lockups with watchdog(8) and helper drivers. Or you can change hardware parts.
