Wenn der NFS Server nicht mehr mitmacht, bleiben Zugriffe auf dem Client im Kernel Mode stecken (Status D = "Uninterruptible sleep"). Wenn das der (einzige) snmpd-Prozeß ist, dann ist SNMP auf der Maschine anschließend in Mors - meines Wissens bis zum Reboot (da der Prozeß den UDP Port blockiert hält und anders nicht wegzubekommen ist). Ohne die Zugriffe irgendwie zu vermeiden, ob jetzt (wie durch besagte Option) im snmpd oder per Config-/Plugin-Änderung auf Nagios-Seite, ist also kein Blumentopf zu gewinnen. Im zweiten Fall können natürlich auch immer noch andere SNMP Clients den snmpd in diese Falle jagen.
Wenn man den Tod des snmpd irgendwie verhindern kann, kann man sich darum kümmern, wie Nagios die äquivalente Information von ihm abfragen kann, ohne daß der snmpd selbst dabei stirbt. Da kämen dann wohl in erster Linie die Agent Extension Mechanismen des Net-SNMP snmpd in Frage, wobei ich nur bei der AgentX-Variante einen Timeout in der Config-Syntax sehe, mit dem sich der snmpd eventuell selbst von leichenstarren externen Prozessen losschneiden kann. In allen anderen Fällen müßte die zu bauende Extension wohl selbst dafür sorgen, daß trotz totem Mount noch ein Resultat an den snmpd geht.
Die blockierten Prozesse stapeln sich und sie sind keine Zombies, insbesondere belegen sie auch weiter vMem der Maschine. Wo ich bisher (allerdings ohne SNMP) NFS Mounts auf Funktion überwacht habe, war es deshalb das wichtigste Feature, daß nach einem "Verdacht auf Tod" nur noch in großen Abständen ein wirklicher Test ausgeführt (und bis dahin nur der gecachete Error zurückgegeben) wurde.