munin-monitoring / munin

Main repository for munin master / node / plugins
http://munin-monitoring.org
Other
1.98k stars 472 forks source link

Can't use an undefined value as an ARRAY reference at /usr/lib64/perl5/vendor_perl/5.20.2/Munin/Master/HTMLOld.pm line 695. #430

Open l29ah opened 9 years ago

l29ah commented 9 years ago

munin-2.0.25 in Gentoo. Removing the contents of /var/lib/munin as in http://munin-monitoring.org/ticket/1219 didn't help.

ssm commented 9 years ago

Could you add some more information to help me reproduce the issue, please?

Do you get graphs and pages, as well as that message, or is that message the last thing you see on the screen before the laptop catches fire? (or something in between)

l29ah commented 9 years ago

On Fri, Apr 10, 2015 at 07:06:04AM -0700, Stig Sandbeck Mathisen wrote:

Could you add some more information to help me reproduce the issue, please?

Do you get graphs and pages, as well as that message, or is that message the last thing you see on the screen before the laptop catches fire? (or something in between)

I get the following at munin/index.html, then munin-cgi-html crashes:

Status: 500 Content-type: text/html

Software error:

Can't use an undefined value as an ARRAY reference at /usr/lib64/perl5/vendor_perl/5.20.2/Munin/Master/HTMLOld.pm line 695.

For help, please send mail to this site's webmaster, giving this error message and the time and date of the error.

() ascii ribbon campaign - against html mail /\ http://arc.pasp.de/ - against proprietary attachments

bldewolf commented 9 years ago

I just ran into this problem on a fresh install of net-analyzer/munin-2.0.19-r1 on gentoo. I tracked the issue down to /var/lib/munin/htmlconf.storable not existing. It wasn't being generated because munin-html was dying early with the error

2015/07/15 10:52:28 [ERROR] Could not copy contents from /etc/munin/static/ to /var/www/localhost/htdocs/munin

The default gentoo apache config serves the static content directly from /etc/munin/static/, so I commented out the call to copy_web_resources() in HTMLOld.pm and now htmlconf.storable exists and the CGI appears to be working.

montjoie commented 8 years ago

I have this problem, and /var/lib/munin/htmlconf.storable exists (removing it, touching it, does not solve the issue) (Gentoo with net-analyzer/munin-2.0.25-r1)

bldewolf commented 8 years ago

Does munin-html die? Check /var/log/munin/munin-html.log. The file needs be correctly populated, not just existing.

Also, my long-term fix for this issue was to add htmldir /tmp/munin-html to my munin.conf. The htmldir variable only seems to be used for copying the content (in CGI mode), but I have my web server serving it directly from its original location.

chriscroome commented 8 years ago

I had this error for a while while setting up the Debian Jessie Munin package, but then it went away at some point, sorry not to have been very methodical regarding documenting what exact steps I followed, I can share the working config I have if that helps anyone, I'm using cgi to generate the graphs.

sstj commented 8 years ago

I have also been getting this error for ages. I decided to debug it today. (Gentoo with net-analyzer/munin-2.0.25-r1like most of you guys(!)).

munin is configured as FastCGI. This means the same process will serve several requests. If I press F5 in a loop, every other request fails. I think the process is terminated on error, giving me a fresh working process for the next request.

The only place I can find that generates htmlconf.storable is the following lines https://github.com/munin-monitoring/munin/blob/stable-2.0/master/lib/Munin/Master/HTMLOld.pm#L162-L184 I don't have a htmlconf.storable (as the comment says "full munin-cgi-html - should not exist!").

The bug seems to be in HTMLConfig.pm:generate_config. ( https://github.com/munin-monitoring/munin/blob/stable-2.0/master/lib/Munin/Master/HTMLConfig.pm#L34-L64 )

1) generate_config seems to always be called with $use_cache=1 2) first thing it will do is set $cache=undef; 3) It fails to read htmlconf.storable, falls thru 4) Looks like it reads data and checks that the revision number hasn't changed from the previous run => we don't need to regenerate stuff, and can return $cache 5) But $cache was set to undef in 2)

Changing the first line to if (0 && $use_cache) { as a workaround fixes the problem for me.