Josip Rodin

Observing the same problem with version 6.0.6-1~bionic1 ``` % sudo passenger-config reopen-logs Reopening logs for Phusion Passenger watchdog Reopening logs for Phusion Passenger core (through reinheritance) All done % sudo...

It seems it's actually completely broken because it thinks that RabbitMQ will record a queue for a channel listing of uncomitted messages, but it simply doesn't https://github.com/ask/rabbitmq-munin/issues/15#issuecomment-24799042

Sorry, I happened to stop using this particular combination in the meantime

It looks as if IO::Socket::INET6's Timeout setting is worthless, because if Munin can't connect to a dead node, /usr/share/perl5/Munin/Master/Node.pm will not actually emit the message ``` if (! $self->{reader} )...

In any event, a defensive approach would definitely be to clamp individual worker timeout with the global timeout. What would be the use case of allowing any worker to continue...

It should also be noted that `plugins/node.d/munin_stats` and `plugins/node.d/munin_update` don't autodetect or allow `update_rate` changes to be configured, so their warning and critical thresholds are wrong after it's changed, as...

With munin-async, this gets better, because the master munin-update job seems to spend some time on the live nodes, and then about ~45 seconds into it, mass discards various dead...

OK so after some time, I can say it's better, but not actually working. Clients that stall out ssh connections more than 60s are not actually timed out after the...

I suppose it needs to be said explicitly - Munin/Master/ProcessManager.pm containing hardcoded numbers for the 3 *timeout variables is clearly wrong given the configurability of update_rate, I don't see any...

> ssh -oConnectTimeout=55 ? That's the initial connect timeout, not the session duration timeout