Dear Maintainer,

as the subject says, munin-html fails with

2014/09/15 13:14:01 [ERROR] Could not copy contents from /etc/munin/static/ to /var/cache/munin/www

when the static dir contains files readonly (mode 444). It shouldn't.
It should warn, but then go on (and possibly use old files), but not entirely break.

bye
 Joerg

Hi Jörg,

thanks for your bugreport(s)!

What should munin-html do, when it cannot write to /var/cache/munin/www, given
its purpose is to update the html files?

Looks like failure is the sanest option.


cheers,
	Holger

But it can write to it. It just copied *one* file with a mode of 444 and
then it breaks.

I don't think it's sanest. It's easiest, yes. But the failure here is
that it couldn't copy the static subdir (actually just one file of it,
but the used perl module for this is just too bad to tell you), it could
just go on with all the rest and actually generate the html output it
has to do. If that also fails, then sure, bug out, but because of random
support files (sure sure, the interface is ugly without them, but existing).

Holger, you might have misread the bug. To me, ignoring the faulty
file for static stuff seems a sane default indeed.

Besides, stopping meanwhile updating the generated files isn't good
either, as the end user has then not many clues of what was wrong. And
users do _not_ read log files. It's very sad, but it's a fact :-).

So, I guess for static stuff I could change the default to the good
old VB "On Error Resume Next".
And for the templates stuff, I think any error could be written in the
output file, in a big fat red font. But in the expected place, so the
user has a change to see it.

That said, the way it works currently has also its adepts. Mostly
because a silent failure is sometimes better than a loudly one.
Specially for tech-sawy users, or for transient ones.

The last behavior should then be optional. The default is still to be
decided, but I usually favor ease-of-use for a newbie, so the red
warning has my personal preference.

to clarify from Jörg just explained on irc: the first time that file with 444
gets copied nicely, on the 2nd run it fails badly...

Yep. Maybe output a log message about not updating it due to $whatever,
but don't stop the whole run.

Ay, though that one has less chance of getting bad the way i described.
Most errors in templates are pretty visible to users :)

I'm not sure it has any advantage to fail in this case, ...

... but having it configurable, no matter which way is default, is
certainly fine.