3 ms·
The hard problem is, it never crash so obviously like the author charmingly presented as echo c > /proc/sysrq-trigger. When something went bad(mostly hardware
by ezoe 5y ago
The hard problem is, it never crash so obviously like the author charmingly presented as echo c > /proc/sysrq-trigger.
When something went bad(mostly hardware or rare edge case bug on software), it works mostly fine but randomly fails and no amount of hard coded sane checks can automate the detection. It either not crash(unusually slow or garbage result), or crash but it happens rarely enough to never go beyond the threshold of supervisor's restart strategy, so the supervisor keep restarting the unstable process rather than crash and let the parent supervisor know to remove itself from the cluster of nodes.
- svrtknst 5y ago"Crash" can mean a lot of things, and in Erlang, a crash occurs whenever your functions are unable to perform their task (for instance, there were no functions that match your input data), or when process calls time out. More obvious crashes exist as well - a remote connection hangs up, a computer catches on fire, etc. You could also use a variety of supervisor strategies or methods to detect what caused the crash.
- NavinF 5y agoYep. Or one RPC call suddenly becomes slow because of a partial failure like a disk retrying sectors and that slows down the whole application to a crawl :(