N-1 times, where N is the number of alerts. This means that, in 1.4.6, all users receiving alerts will now only receive the first alert and the others will be lost.

Also, to respond to a question in the original ticket: Munin opens a handful of processes per contact to catch and log stdout/stderr. It doesn't seem particularly effective or necessary, but that's why. It's also why the processes have intermingled pipes between them.

Anyway, I've setup a test environment with two mail commands and I can't get it to trip up the same way. The one caveat is that munin-limits makes no attempt to put time limits on the commands it opens. So if your mail commands are stalling for some reason then munin-limits is going to stall until they come back.

I'd love to get more information on how to reproduce this properly so I can fix it because it's currently got 1.4.6 in a really broken state.

I was finally able to reproduce this in a test environment and it seems some interaction between open with the "" mode and having lots of opened processes was causing deadlocks. Since trunk already moved towards removing the extra processes, I pushed it further with r4400 in both trunk and 1.4-stable so that munin-limits won't trip over itself while dealing with contact commands and also won't get stuck waiting for them when finishing up. Hopefully this puts the issues with calling out to commands in munin-limits to rest for good (it did in my test environment, anyway!).