/etc/rc.sysinit purges the contents of /var/lock during boot time, so the creation of the /var/lock/munin directory needs to be moved out of the install scriptlet and into the rc.d script.

Another, possibly simpler, solution might be to store the lock files directly under /var/lock without having a munin subdirectory.

Ahh, shoot. Thanks for reopening and explaining it clearly, I'll try to take a look at this time but I am a bit swamped lately. If you try adjusting the patch I made to move the lockfile into a different directory to put the file directly in /var/lock/, does it work? That would probably be the easiest fix if so.

Putting the lock files directly under /var/lock does indeed solve this issue.

I'm attaching the changes I did to the package. These are:

- Set LOCKDIR to '$(DESTDIR)/var/lock' in Makefile.config.
- Removed the hunk regarding Makefile.config from munin-lock-location.patch since the changes are applied to Makefile.config itself.
- Deleted references to /var/lock/munin from the install scriptlets.

Here's how I tested:

1) On a server with munin 1.4.5-4 installed, I removed the /var/lock/munin directory.
2) I ran 'sudo -u munin munin-cron' and got the expected errors:

Creating lock /var/lock/munin/munin-graph.lock failed: No such file or directory
at /usr/share/perl5/vendor_perl/Munin/Master/GraphOld.pm line 248
Creating lock /var/lock/munin/munin-limits.lock failed: No such file or directory
at /usr/share/perl5/vendor_perl/Munin/Master/LimitsOld.pm line 114
Creating lock /var/lock/munin/munin-html.lock failed: No such file or directory
at /usr/share/perl5/vendor_perl/Munin/Master/HTMLOld.pm line 151

3) Installed the modified packages (both munin and munin-node, since the latter includes the Defaults.pm file which contains the paths). I then reran 'sudo -u munin munin-cron' and the graphs were updated with no errors returned.

Experiencing the same issue, I need to recreate this directory manually each time, so it would be great if the patch could be merged into the package.

Wouldn't the simplest solution be that the munin-cron script creates the /var/lock/munin directory if it doesn't exist?

@Dan: Would it be OK with you if I implemented the change I describe in my previous comment and pushed updated packages to [extra]?

I don't know why you removed a hunk from munin-lock-location.patch needlessly. This should be submitted to upstream like this, not changed because it works better that way for Arch.

Sorry for the huge delay here, but I have applied this and a few other fixes, along with some upstream SVN checkins due to the lack of release, and released a new set of packages.

A locking issue remains:

--8<------------------
# sudo -u munin munin-cron
Creating lock /var/run/munin/munin-update.lock failed: Permission denied
at /usr/share/perl5/vendor_perl/Munin/Master/Update.pm line 128
--8<------------------

The following is a change from the upstream SVN commits pulled into 1.4.5.stable-1:

--8<------------------
Index: master/lib/Munin/Master/Config.pm
===================================================================
--- master/lib/Munin/Master/Config.pm (.../tags/1.4.5) (revision 4208)
+++ master/lib/Munin/Master/Config.pm (.../branches/1.4-stable) (revision 4208)
@@ -148,7 +148,7 @@
local_address => 0,
logdir => $Munin::Common::Defaults::MUNIN_LOGDIR,
max_processes => $MAXINT,
- rundir => '/tmp',
+ rundir => $Munin::Common::Defaults::MUNIN_STATEDIR,
timeout => 180,
tls => 'disabled',
tls_ca_certificate => "$Munin::Common::Defaults::MUNIN_CONFDIR/cacert.pem",
--8<------------------

I think rundir should be changed to $Munin::Common::Defaults::MUNIN_LOCKDIR. That's the value mentioned as the default in /etc/munin/munin.conf, and the value used in /usr/share/perl5/vendor_perl/Munin/Master/Utils.pm.

Attached is an updated munin-lock-location.patch that works for me.

Ugh, this piece of software astounds me in how complex it has managed to get. Sorry for all the troubles here, I've updated the old patch with the new hunk and rebuilt. Let me know if you see any problems (or if it is finally working as expected).

I don't see any issues with the new packages.

Thanks!