#1289 closed defect (fixed)

munin is trying to create graph in /

Reported by: aversag Owned by: nobody
Priority: highest Milestone: Munin 2.0.10
Component: design Version: 2.0.6
Severity: blocker Keywords:


I have a munin server 2.0.6-1~bpo60+1 on a debian server which has problem to create some graph for some specific remote nodes

after analyse with strace, it seems that munin was trying to generate the png for the graph on the directory "/"

somebody gave me a workaroud which is to create a symlink for the subdomain in / to the var/cache/munin/www/subdomain directory but that's not really clean

Change History (2)

comment:1 Changed at 2013-12-15T21:28:20+01:00 by cbiedl

Hi there,

sorry for not getting back to you earlier. This is clearly a bug in munin
but without detailled information it took quite some time and the
help of a fellow in IRC who suffered from the same problem to create
a reproducer.

I don't have a full analysis yet, but munin-graph starts causing
trouble if running for more than 300 seconds. So the possible
workarounds for you are:

  • Apply the patch from #1394 that will quarter the run-time of munin-graph most of the time.
  • Switch to CGI based graphing.

Now, some things that are or might go wrong:

munin-graph loads the munin configuration at startup, then calls
graph_main for each graph. The code in GraphOld.pm has a protection
against reading the configuration file every time again. However it
will read it one time anyway since the protection does not work when called
from an external program. Additionally, GraphOld checks whether the
configuration is stale, by looking at the time stamp of datafile.
And triggers a reload if required, this will happen if the next time
munin-update sucessfully ran, five minutes minus munin-limits
run-time later.

For reasons I didn't fully investigate, that re-reading also affects
$config in munin-graph, making it undef or an empty hash.
Subsequently, accessing htmldir yields an empty string plus a
missing initialization warning, and a file name starting at /.

Related, graph_main checks the lock file every time. It seems saner
to me to put the locking into munin-graph and run graph_main with the
--skip-locking parameter if possible. At the moment, the lockfile
check seems to affect a single graphing only and does not cause any
second munin-graph process to terminate (why?). Once the old and
long-running munin-graph process has finished the job, graphing
continues as planned. This might result in unpleaseant effects if
munin-graph takes even longer than ten minutes.

So, no patch this time. Need some more time to think about it.

Last edited at 2013-12-15T22:06:09+01:00 by cbiedl (previous) (diff)

comment:2 Changed at 2014-03-20T17:54:05+01:00 by snide

  • Milestone set to Munin 2.0.10
  • Resolution set to fixed
  • Status changed from new to closed

The fix for that is 6d62e6b0782ecfa0f4e0c2bec14434d675734962, which is in 2.0.10.

Note: See TracTickets for help on using tickets.