29f4223 patched it, but failed to take the ?0 into account. Using the patch from debian #683064 is better.
This was added in commit e86f958 without further explanation. OpenVZ uses a filesystem type of simfs for all the mounts so this makes munin more or less useless on OpenVZ guests. The device name is useless though. Typical example: Filesystem 1024-blocks Used Available Capacity Mounted on /dev/simfs 398458880 91795132 306663748 24% / varrun 2097152 28 2097124 1% /var/run varlock 2097152 0 2097152 0% /var/lock /dev/simfs 330279532 15616532 297885784 5% /opt/zimbra/backup
Graph fcgi that stops working and exits after a short time. When the dbdir is changed it start by creating graph correctly, but after a munin-update run, it tries to search for rrd in the default dbdir and as it can't find them, crashes.
First of all the ipmitool command might not be in /usr/bin (in Gentoo it's in /usr/sbin); second of all instead of checking whether the ipmi driver is loaded (and then fail if the ipmi device is unavailable to the munin user), check whether ipmitool is able to fetch the sensors. The ipmitool command supposedly works with Linux, Solaris 10 and FreeBSD.
Some file systems do not have inodes, which make "df" report a "-" instead of a number. If the used and available inode field is not numeric, it does not make sense to try to calculate a percentage. If that happens, we skip calculating inodes for this filesystem.
This basically makes --cron work again.
This already happens for the cgi version.
Without this, the comparison and category pages will create the wrong URL to the images and won't display.
This unbreaks the default generation of the graphs when not installing the CGI (before, it would have worked if the CGI was in place).