On Fri, 10 Mar 2017, Simon McVittie wrote:
However, Matthew Gabeler-Lee's reply:
I argue this merits worse than "important" -- in a default install of
Stretch currently, munin doesn't work at all.
suggests that there may be something else going on.
Matthew, please could you describe what you did (before applying any
workarounds), what you expected to happen, and what actually happened,
including any syslog, Journal or web server log messages that look
potentially relevant?
On closer inspection, I think I need to retract my prior statement.
I had a problem with munin "not working at all" -- i.e. not collecting
data / updating charts, which correlated with an upgrade of the munin
package.
But on closer inspection, I realize two things happened that day, and it
was actually the other thing that "broke" munin, and it was a mistake
interpreting the munin status pages that made me thing the sysvinit
workaround "fixed" it. The sysvinit hack "fixing" things was a false
positive, and it was really fixing the other problem (a network issue
preventing data collection from most nodes) that made munin start
working for me.
I think the suggestion that this in fact is not a bug and is just a
confusion with how munin works is correct.
It is in fact /etc/cron.d/munin that does the "service" work of munin.
Apologies for the confusion!
--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
