0

I recently installed munin on my (Fedora12 based) server. Now, I wanted to get all the graphs in a static directory (The application runs on Django). So, I edited the file /etc/munin/munin.conf by setting the htmldir as the absolute path to my static folder. Then, when I did a munin-cron, I got the following error:

This program will easily break if you run it as root as you are
trying now.  Please run it as user 'nobody'.  The correct 'su' command
on many systems is 'su - munin --shell=/bin/bash'
Aborting.

So, I changed the user and tried running the same with munin as a user. I then got the following error:

[ERROR] Could not copy contents from /etc/munin/static/ to /[path to static 
file] at /usr/share/perl5/vendor_perl/Munin/Master/HTMLOld.pm line 716.

I chown-ed the static directory (recursively for the munin user) and even tried with chmod 777 (which actually one shouldn't do), so basically it doesn't seem to be a permission issue.

Also, my dev server is Ubuntu (12.04) based. It worked fine there. It worked fine even with my local machine running Ubuntu (14.04). Can this be an OS issue? That is highly unlikely it seems. What other thing could I be missing? Any help would be appreciated.

PS: There is one more catch. When I ran munin-cron as root in my Ubuntu(s), the error it gave was:

This program will easily break if you run it as root as you are
trying now.  Please run it as user 'munin'.  The correct 'su' command
on many systems is 'su - munin --shell=/bin/bash'
Aborting.

whereas it was nobody here. Can it be a configuration issue?

My munin version is 2.0.16.

Ranveer
  • 111
  • 1
  • 6

6 Answers6

1

You should never run munin-cron with 'root' user.

Try running this command:

 chown -R munin:munin  /var/www/munin

After this try running "munin-cron" back from the "munin" user.

0

To get more informative error messages, You can comment out the line in the Perl Module that calls die().

go to line 795 in /usr/share/perl5/vendor_perl/Munin/Master/HTMLOld.pm

and change

sub copy_web_resources {
    my ($staticdir, $htmldir) = @_;
        unless(dircopy($staticdir, "$htmldir/static")){
                ERROR "[ERROR] Could not copy contents from $staticdir to $htmldir";
                die "[ERROR] Could not copy contents from $staticdir to $htmldir";
        }
}

to

sub copy_web_resources {
    my ($staticdir, $htmldir) = @_;
        unless(dircopy($staticdir, "$htmldir/static")){
                ERROR "[ERROR] Could not copy contents from $staticdir to $htmldir : $!";
                #die "[ERROR] Could not copy contents from $staticdir to $htmldir : $!";
        }
}

The $! will add the last OS error code. For me it is File exists.

But this is misleading.
The commented out line will not protect Munin from exiting; but it will create more informative error messages. I receive a lot of Permission denied errors in the output of systemctl status munin.

For me I suspect that they have to do with SELinux, but this is another matter. I am still investigating, actually.

Update:

I might have misconfigured the SELinux context of the default HTML parent direcory.
This command, suggested by the setroubleshoot-server tool, seems to solve the issue, for now:

sudo /sbin/restorecon -v /var/www/html

knb
  • 161
  • 5
0

At first:
You can run munin-cron only as user munin, so it's not an error that you can't run it as root.

There are some few more Details in the Log Files ?
On my Ubuntu Systems they are in /var/log/munin/

Which Version of Munin runnig on your Fedora Server ? Maby a Bug in Munin ?

CookieCrash
  • 96
  • 1
  • 8
  • I just did a `yum install munin`. I'm unable to check the version. `munin-node-configure --version` returns something arbitrary. What log files details would you need? – Ranveer Jun 15 '14 at 17:27
  • The munin version is `2.0.16`. Is that a version bug? Also, why does it say `nobody`? – Ranveer Jun 16 '14 at 07:05
0

You can change into the Munin User with su - munin --shell=/bin/bash
To show the version number use munin-cron -v
The first line was something like munin version 1.4.6.
This works for me (Ubuntu 10.04/12.04/14.04).

Munin has five Binaries they Work together:
munin-update - collect the Data
munin-graph - create the Graphs
munin-limits - check if services critical/warning (if configured)
munin-html- builds the HTML Pages
munin-cron - call the other binaries

So if you (or your Cronjob) is call munin-cron all binaries do her part.
Every binary writes his own Log File (standard in /var/log/munin/) named by the binary.
Take a look in the Log Files, maybe you see which one failed.
Often Log Files contains more information as the "Error Code".

CookieCrash
  • 96
  • 1
  • 8
  • Yep! It shows `munin version 2.0.16`. – Ranveer Jun 16 '14 at 06:56
  • Also, in the `/var/log/munin`, I've got 3 log files - *munin-html.log*, *munin-limits.log* and *munin-update.log*. Which of these would contain the error? I checked *munin-html.log* and all it says is: ` [ERROR] Could not copy contents from /etc/munin/static/ to ` – Ranveer Jun 16 '14 at 06:59
0

I know this is a bit late, but I found this when searching for this issue on Google so maybe it may help people.

While running munin-check doesn't report any errors, what I found by entering into a shell as munin, is that the permissions of the parent directories to the munin stats html folder were wrong. Try entering a shell as munin and then entering into the nginx stats folder using cd.

I did this:

sudo su - munin --shell=/bin/bash
cd /var/www/html/stats/ #stats directory under apache2 on my system

I got this message:

-bash: cd: /VAR/: Permission denied

I then realised that /var/www/html/ itself wasn't accessible to munin. When I fixed the permissions on that, everything worked fine. (I used 755, but this maybe insecure depending on how your system is setup or what you have inside your nginx folder).

0

I solved this error by adding user munin to group nobody (the same as apache's group) and setting the munin directory writable by the group nobody:

chmod -R g+w /usr/local/apache/htdocs/munin

Error stopped. Graphs started appearing again.