On 07/12/15 09:41 +1100, Andrew Beekhof wrote: >> On 5 Dec 2015, at 4:22 AM, Ken Gaillot <kgail...@redhat.com> wrote: >> On 12/04/2015 10:59 AM, Jan Pokorný wrote: >>> (would the exec >>> mechanism apply some kind of rate-limiting to prevent exhaustion?), >>> but what about >> >> There is no rate limiting on the Pacemaker end. If there winds up >> being a big demand for it, we can look into it, but that is more >> likely to be useful within the script itself (a script that notifies >> another service of status changes likely does not want rate limiting, >> but an SMS notifier sure might). > > agreed. this belongs in the scripts or some intermediate party.
More deeper reasoning behind the rate limiting question was that if a fork-exec-forget style is to be applied, you can easily lose the event ordering (be it due to a bad scheduler, high load or not covering the machine with a tin foil hat) which may or may not be acceptable in some cases. [...] >>> long-lived unix sockets or named pipes? Especially the latter >>> might be doable in the agent just in shell + coreutils and other >>> basic tooling and might play well with file discovery approach. >> >> Simple shell scripts are often the limit of sysadmins' abilities in >> this area, so the less they have to know/do the better. Under normal circumstances, such long-lived connections would ensure the correct event ordering. Alternatively, the same effect would be achieved with fork-exec-wait style with per-script queues (and some kind of limiting anyway). -- Jan (Poki)
pgpp2z_a4XEFk.pgp
Description: PGP signature
_______________________________________________ Developers mailing list Developers@clusterlabs.org http://clusterlabs.org/mailman/listinfo/developers
