Что может заставить ВСЕ сервисы на сервер спускаться, и все же ответив на ping? и как выяснить
Для любого, кто прибывает сюда через Google, мне удалось заставить его работать со следующим правилом:
<rewrite>
<rules>
<clear />
<rule name="Force HTTP" stopProcessing="true">
<match url="(.*)" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTPS}" pattern="on" />
</conditions>
<action type="Redirect" url="/{R:1}" redirectType="Temporary" />
</rule>
<rule name="Allow Local Resources" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAny" trackAllCaptures="false">
<add input="{REQUEST_FILENAME}" pattern="SiteMaintenance.png" />
<add input="{REQUEST_FILENAME}" pattern="Stylesheet.css" />
</conditions>
<action type="None" />
</rule>
<rule name="Check Is Root" stopProcessing="true">
<match url="^.+$" negate="false" />
<conditions logicalGrouping="MatchAny" trackAllCaptures="false" />
<action type="Redirect" url="/" appendQueryString="false" redirectType="Temporary" />
</rule>
</rules>
</rewrite>
Никакая идея, если это - лучший способ, но он работал на меня.
:)
(tl;dr still responding to ping is an expected behaviour, check your memory usage)
ICMP echo requests (i.e. ping) are handled by the in-kernel networking stack, with no other dependency.
The kernel is known as being "memory resident", which means it will always be kept in RAM, and can't be swapped to disk like a regular application can.
This means in situations where you run of out of physical memory applications are swapped to disk, but the kernel remains where it is. When both the physical and swap memory are full (and the system can no long manage your programs) the machine will fall-over. However because a) the kernel is still in memory and b) it can respond to ping requests without the help of anything else, the system will keep responding to ping despite everything being dead.
In regard to your problem I'd strongly suspect memory issues. Install "sysstat" and use the "sar" command to see a log of memory/cpu/load/io load etc. I would expect at the times of crash you'd see both 100% physical and swap used.
I would also consider looking at dmesg or /var/log/messages for any sign of the OOM-killer (out-of-memory-killer) being invoked. This is the kernel's emergency system which will start killing processes in the event of memory being exhausted. It's effectiveness depends largely on what processes are being killed. A single process eating up the memory will be efficiently killed and memory freed, however an apache-based website will spawn replacement processes as soon a child process is killed.
Usually, it's an I/O or disk subsystem issue. Often times, this will be coupled with an extremely-high system load average. For example, the system detailed in the graph below became unresponsive (yet was pingable) when a script ran awry, locked a bunch of files and the load rose to 36... on a 4-CPU system.
The services that are running in RAM and do not require disk access continue to run... Thus, the network stack (ping) is up, but the other services stall when disk access is required... SSH when a key is referenced or password lookup needed. SMTP tends to shut down when load average hits 30 or so...
When the system is in this state, try a remote nmap against the server's IP to see what's up.
Your logging probably doesn't work if this is a disk or storage issue...
Can you describe the hardware setup? Is this a virtual machine? What is the storage layout?
More than logging, you want to see if you can graph the system performance and understand when this is happening. See if this correlates to a specific activity.