It can happen for benevolent reasons that a PMDA can't procure
answers to a query relayed by PMCD for more than _pmcd_timeout.
Some transient kernel business could lock up /proc/$pid/FILE for
a few seconds. A burst of I/O could knock out access to a pmda
input log file awhile. A pmda request may contend with application-level
locking over some shared files. Should any of these happen, pmcd
shuns the pmda for the rest of its own lifetime.
It would be desirable not to overreact so badly. PMCD could impose a
timeout on requests, and notify clients. But it should be willing
to exchange further messages with the slow PMDAs, once their in-progress
work finishes up and normal response times return. This is especially
important considering the absence of a capability to restart PMDAs on
demand (which, if overdone, could make a busy system's situation
worse).