With OpenRC 0.9.6 it seems like the intention is to symlink /var/run -> /run .. but that doesn't work very well; indeed /var/run/munin is created by munin-node itself, and it is not created as munin user, so the update script fails badly. I suppose an alternative would be to make munin part of the uucp group and make it use /run/lock, which is created at each boot with 1775...
Okay that's a bad idea as well: on one of my systems it is root:uucp 1775, on another one it's root:uucp 1755 (wth?)... I guess it depends on who creates it.
We need to update all init.d scripts that create subdirs under /var/run, so that they always create them each boot, if /var/run is writable. If it is not writable, and the dir does not exist, they should bail.
The init script already works fine. It's the cron script that fails...
07 Jul 2012; Justin Lecher <jlec@gentoo.org> +files/munin-node_init.d_1.4.7, +munin-1.4.7-r1.ebuild: Add fix when /var/run is on tmpfs ????????
(In reply to comment #4) > 07 Jul 2012; Justin Lecher <jlec@gentoo.org> > +files/munin-node_init.d_1.4.7, > +munin-1.4.7-r1.ebuild: > Add fix when /var/run is on tmpfs > > ???????? oh I didn't checked this bug. For me the complete graph creation completely fails. What I did, was repeating the creation and permission setting from the ebuild inside the init script. Basically what Robin suggested in comment 2. I will add the additional permission check now.
--- munin-node_init.d_1.4.7 7 Jul 2012 07:21:50 -0000 1.1 +++ munin-node_init.d_1.4.7 11 Jul 2012 05:59:28 -0000 @@ -16,6 +16,9 @@ fix_dirs() { local rundir piddir piddir=$(dirname ${PIDFILE}) rundir="/var/run/munin/plugin-state /var/run/munin/spool" + if [[ ! -w "/var/run ]]; + echo "/var/run is not writable" && exit 1 + fi for dir in ${piddir} ${rundir}; do [ -d ${dir} ] || mkdir -p ${dir} chown munin:munin ${dir} Okay in this way?
Sure, if it works. What about the cron script (comment #3) ?
(In reply to comment #7) > Sure, if it works. What about the cron script (comment #3) ? I am not sure. Can we run munin without starting the service? Diego?
Yes we can, and that's where it failed to me.
So I fixed this, hopefully properly, in the 2.0.2 version. Should we backport it or do you think we can close this once we unmask that one?
Closing as FIXED as this is handled in 2.0.